On Sat, Oct 26, 2013 at 11:12 PM, Ben Kloosterman <[email protected]>wrote:
> On Sun, Oct 27, 2013 at 1:41 AM, Jonathan S. Shapiro <[email protected]>wrote: > >> The more complex case is when arrays appear within heap objects, and the >> array element type contains references. In that case you're going to need >> to generate a /this/pointer into the array interior, which is an inner >> reference. There are a variety of ways to handle this particular case >> without going to fat pointers, but it's a nuisance. Also, you can't always >> rely on a dominant live reference unless the compiler is really careful. >> Consider: >> > >> for(int i = 0; i < ar.Size(); i++) { >> var inner = ar[i]; >> (void) inner.MemberCall(...); >> ... >> } >> >> > >> Turns out this isn't safe, because a concurrently executing method can >> perform a store to ar. This changes the array you are operating on, and >> potentially it's length (which is why the i < ar.Size() can't be hoist in >> CLR). >> > > I was thinking unboxed arrays are always fixed length... > Yes. And they are. And so are boxed arrays. But in both cases the array * reference* can be assigned, with the result that /ar/ might name a completely different array from one pass to the next. Just as there are cases of "covering liveness" that can elide reference counts safely, there is a required analysis of "covering constantness" before you can hoist the bounds check on this loop. Variable size embedded arrays are way to hard. > Yes. Though there are motivating cases for dynamically fixed but statically variable arrays, e.g. when an immutable length field precedes a payload buffer (so the array is a dependent type). I wouldn't build support into the language just for that case, but it's qualitatively similar to a bunch of other really useful cases. I would say that from a language-oriented perspective this sort of dependent size isn't motivated. But from a system-wide copy avoidance perspective, I think it probably is. > >> >> There are lots of concurrency hazards like this hiding in CLR and JVM >> that preclude obvious optimizations. Wonder of wonders, we've learned some >> things in the last decade. >> > > Yep... > > That why im against a concurrency safety as a general case. It's a false > promise. > So there are two different issues here, and I actually think you are wrong on both of them. :-) The first might be termed "concurrency safety up to memory safety". That is: making sure that you don't compile stupidly in such a way that concurrency errors lead to memory safety errors. The changing vector base pointer example above is an example of this. The second is "concurrency safety assist", in which the programmer is enabled and required to state their intent. The intent may still be wrong, but at least we can confirm that the intent was implemented. So, for example, I don't know how to test in the general case that a program is deadlock free from a static compiler. I *may* know how to provide language-level annotations that say things like "that lock needs to be held before this field can be touched" and check that they are honored. That doesn't come close to solving the whole problem, but I think it would be a step forward. And then we can build higher-level library constructs on that base. > There are a bunch of DPF-like mechanisms we can use for this. The general >> idea is that the bitmap becomes an instruction stream in a "marker >> language". The opcodes are: >> >> MARK-WORDS N <bitmap> >> ITERATE N <instructions> CONTINUE >> MARK-OBJECT // mark object pointed to by the GC cursor using its >> marking program >> >> That ought to be about all you need. >> > > Dont you need recursion to handle a tree of diffirent sized value types > some of which have references ? > Yes. That's what MARK-OBJECT is for. It assumes that given a *pointer* to an object (remember, we're the GC here), we can locate the marking program. Though come to think of it we probably want MARK-TYPE <ty> instead. The idea is that we are incorporating the marking program of the other type by reference (recursively). So we get programs like: MARK-WORDS N <bitmap> ITERATE N MARK-TYPE <some-inner-type> CONTINUE shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
