> >> Pulling away from these details, the fact remains that there is no >> successful model for having two different GC tracing systems coordinate to >> determine reachable resources. This forces us to express all boundaries out >> of the GC systems in terms of non-tracing memory management contracts. >> > > That's not quite true, but it's nearly true. Singularity stands out as a > counter-example. > > The interesting cases here are the cases in which two "processes" running > in separate heaps want to share an object by reference. It isn't hard to > register "foreign" roots for such objects, and it isn't that hard to make > the respective GC's concurrent enough that the mark passes don't step on > each other. The practical challenge turns out to be the object header > structure. Different styles of GC tend to want different information in the > object header. When cross-heap references occur, sanity of implementation > tends to push you toward a *common* object header. > > But the practical impact of this is pretty limited, because the data that > can *usefully* be shared across processes tends to be "mostly reference > free", and the number of heap-exiting pointers involved for any given > process tends to be small. The collector has to deal with foreign pointers > anyway (e.g. pointers to native objects), so it already needs to recognize > pointers to things outside the heap. It's therefore possible to imagine > designs in which a dedicated "shared" heap is used, and the shared heap > uses a compromise object header structure that is commonly handled by all > participating GCs. This is effectively what Singularity does. > > The limitation in that design is the problem of copy avoidance. In > practical systems, most of the benefit of cross-heap object sharing is a > result of copy avoidance. To achieve copy avoidance in the Singularity > shared heap style of design, you need to plan ahead and build the object in > the shared heap in the first place. When this requirement is combined with > linear types (which is how Singularity managed content in the shared heap), > the result is very hard to use. There are *many* codes that would like to > operate on things in the shared heap that have fork/join patterns in their > control flow. Linear types don't tolerate such control flow. Network > stacks, as one example, involve lots of these. > > So in practice, the problem in Singularity had nothing to do with GC at > all. It had to do with the decision to use a typing mechanism whose > limitations were a bad impedance match for the problems people were > actually trying to solve. I wonder, in hindsight, whether some combination > of ARC and borrowed pointers would not have worked better. > > > 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 . 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 ..
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) .. but the objects represented for winrt itself tend to be system objects ( file handlers / capabilities etc) . Note within a component you can use local referneces , GC etc . Ben
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
