On Thu, Aug 22, 2013 at 9:31 PM, Bennie Kloosteman <[email protected]>wrote:
> > Im gkad i wasnt the only one who thought the typesafety of singularity > IPC used a rather heavy approach for a low level system ( I have seen IDLs > used for cross machine services but not like that) ..its a wonder this > didnt kill performance . > Well, let's look at the goals and the tools they had available. As a refresher for those who may not know, a Singularity "process" combines a GC heap and some number of associated threads of control. Non-scalar communications between processes is accomplished by placing objects in a distinguished "shared heap" and then passing a reference from one process to the next. There were several strong goals for the shared heap: 1. Every object in the shared heap is accessible to *exactly one* process. This was accomplished using linear types. It is never necessary to run GC to reclaim space in the shared heap. 2. Because objects in the shared heap are not GC'd, and there are no direct linkages from one process to another, distinct heaps are free to implement distinct GCs. The majority of data that moves in the shared heap is non-reference scalar data. For such data the model works very well. The part that *doesn't* work so well is object graphs. Here's the problem: if a process *does* own an object graph in the shared heap, it needs to *traverse* that graph using object references. But if the object graph is transferred, those references need to be efficiently rendered invalid (because of the linear type contract). Further, this needs to be done in such a way that the process whose references are nullified behaves sensibly after nullification. The hidden problem with nullification is that actions by one part of the process (a transfer) can cause existing references in another process to be nullified *after* validation has occurred (i.e. after a check has been made to determine that the reference hasn't been nullified). This is pretty bad. It's as if pointers can spontaneously become null underneath running code that is using those pointers. It's *very* tricky to write correct algorithms under these conditions. While linear types enforce the desired properties, the fact that they can't handle fork/join behavior turns out to be a pretty significant impediment. One alternative would have been borrowed pointers, but that would have required significant further changes to the compiler, which *may* have been beyond the level of developer resource that Singularity had available (I don't know). Separately, there are cases, for example, where we would like to implement a stream of some sort between processes. That was hard. Perhaps ARC would have worked, but ARC would mean giving up one of the motivations for linear types: isolation. If exactly one process can hold a reference to something in the shared heap, then we know that no action by any *other* process can alter the data in that object. That's a surprisingly important guarantee in some cases. I think we need to be careful about passing judgement on solutions before we have a clear understanding of the problem they were trying to solve. Singularity may or may not have been solving the right problem (it's not obvious to me one way or the other). Given the problem they said they were trying to solve, linear types were a pretty exact fit. > Regarding ARC didnt Singularity have an ARC GC which you can state in > MetaData ? DIdnt they test this ( the borrowed pointers is a further > optimization ) ? Arc is certainly attractive for system objects .. > I don't know about the "ARC in metadata" question. Yes, ARC *is* attractive for system objects, except that it doesn't address the issue of isolation. > Note winrt uses ARC and weak references like borrowed pointers and it was > certainly influenced by singularity. ( You take a weak reference and use > it for reads) .. > I'm not aware of any borrowing from Singularity that occurred in WinRT. Are you speculating, or can you point to something that confirms this? shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
