OK. I want to recap where we are on interior objects, and see if we can drive this thing to ground. The problem is that if interior references are used (and in a region-oriented system they *would* be), then we need to make their write barriers efficient. But if we add a GC header to these objects, we lose layout compatibility with C.
Let me say, first, that I'm not compelled by C layout compatibility for * objects* (that is: heap types). C can't express objects, so it doesn't seem problematic that objects aren't layout-compatible with C. And for *new* C code, we can make the C structures do what they need to do. I'd be content if we can make *value* types interoperable with C. And incidentally, the runtime discussion has served to clarify for me why the boxed/unboxed distinction wants to be part of the type hierarchy. So let's look at that object header again. Since relocation and marking and such only occur on exterior objects, there are a lot of fields in the object header that we do not need on *interior* objects. Some of these would be nice to have, but we don't strictly *need* them: - Size in words - can get this from modified immix metadata - Tri-color color - only relevant on exterior object - Pin - only relevant on exterior object - FF - only relevant on exterior object, and I'm now going to assume a page faulting forwarding barrier. And that leaves.... the 'M' bit, which exists for deferred reference counting. It seems to me that there are several options here: 1. Find a place for the 'M' bit. 2. Store the 'M' bit someplace else. 3. Treat potentially interior references as a distinct type, and run a more expensive barrier on them. 4. Use non-deferred reference counts on fields accessed through a potentially interior reference count - except this turns out not to work unless you can solve the logging problem, and if you've solved that, you're done. 5. Give up on deferred RC entirely. 6. Adopt size-partitioned blocks in the main heap 7. Give up interior references Of these, the most promising approach seems to be storing the M bit someplace else. So here's a thought experiment: Suppose that, instead of storing the M bit on the object header, we record M on a per-line basis. So now we're not logging objects; we're logging immix lines. The rule is that you log the current line and any "continued" lines. If we do that, then we don't need the 'M' bit to be inline with the object. Does that let us do it sensibly? And if so, is this approach useful for anything else? Do we want to consider forwarding *lines* rather than * objects*? shap
_______________________________________________ bitc-dev mailing list bitc-dev@coyotos.org http://www.coyotos.org/mailman/listinfo/bitc-dev
