Proxying built-ins (Was: [[Invoke]] and implicit method calls)

Brendan Eich brendan at
Thu Sep 26 14:14:30 PDT 2013

> Mark S. Miller <mailto:erights at>
> September 26, 2013 8:55 AM
> I think we need to distinguish two senses of process when we ask this 
> question:
> a) address space separation in the implementation
> b) concurrency
> #b would be a breaking semantic change, so I'm going to write that off 
> here. Feel free to start a separate thread on public-script-coord if 
> you like about whether this breaking change might be possible, but I'm 
> skeptical.

IE9 and above use multiple processes, and I'm told sometimes 
does a DCOM thing and everything's racy after that: setting,, etc.

I'm sure MS folks will correct me if I'm wrong, but I can believe this 
is "compatible enough".

> #a without #b might make use of OS processes in the implementation, 
> since most OSes only provide separate address spaces to separate 
> processes. But from a scheduling perspective, a group of address 
> spaces can function as a single process by adopting the discipline 
> that at most one is active at a time. A sync IPC makes the caller 
> inactive and the callee active. It simulates exactly the locus of 
> activity we have now in a single process single thread implementation.
> So the #a question in isolation really does reduce to the membrane 
> question. Since no object references ever directly cross a membrane 
> boundary implementing a realm boundary, the two sides of a membrane 
> can be connected by only a bit channel with no loss of *observable* 
> functionality. However, we'd lose the easy GC of cross compartment 
> cycles we get right now by building in-address-space membranes using 
> proxies and weakmaps. Cross-address-space GC is essentially the same 
> problem as distributed GC, which is a big topic in itself.

Distributed GC is harder still because of network partitioning and 
multiple machine failure scenarios, but you're right that the cycle 
collection problem arises with multi-process GC, as with 
multi-language-VM-heap and with distributed multi-machine.


More information about the es-discuss mailing list