On Wed, Jul 31, 2013 at 11:31 AM, David Jeske <[email protected]> wrote:
> On Wed, Jul 31, 2013 at 10:44 AM, Jonathan S. Shapiro <[email protected]>wrote: > >> The problem is that the slot containing the *reference* to the vector is >> mutable. >> > > I don't understand why these concurrency issues are getting dragged in. I > really dislike the idea of the bare runtime enforcing concurrent behavior > interactions. > If the runtime is responsible for enforcing memory safety, and the runtime admits concurrency, then its implementation has to take into account the potential memory safety impacts of concurrency. I'm 100% okay with the existing common reference semantics that say my loop > operates over the concrete vector which existed when the loop began. As > long as that vector doesn't disappear underneath me (which it wont because > I hold an independent pointer to the box on my stack), then I'm fine. All > this commentary about the field-mutability is mixing in concurrency issues > which IMO should be addressed by concurrency primitives, not the loop code > generation. > You are assuming that the box containing the independent pointer is in fact independent. Because of the introspection and concurrency features of CLR, this assumption is wrong *in the CLR*. There are many other complications arising from dynamic introspection, including the exception performance issues that we've identified here. Quite apart from the concurrency implications, I think it's worth asking whether dynamic introspection is worth what it costs. > When I am addressing concurrency I can specify the behavior and write the > code to produce the desired result. > Not knowing you personally, I hesitate to comment on whether you personally can do that. I'm quite confident that the overwhelming majority of programmers *can't* do that, and that I don't know even *one* expert programmer who can accomplish this with 100% consistency. STM and/or deep-immutable COW might be interesting here... > Perhaps so. Unfortunately, performant support for COW in a runtime, without support from a hardware MMU, is well beyond the current research state of the art. I'm certainly not opposed to using MMUs, but I'm reluctant to put features in a programming language that can't be implemented practically * without* an MMU. > You might think that making a stack-allocated copy of the vector reference >> would help, because *that* really *is* a single-thread slot. Except that >> one thread can engage stack introspection on another, so actually it isn't >> clear whether that helps. And note that if it *does* help, that raises >> interesting optimization precondition quandries for termporary introduction >> during rewrites. >> > > Is this about the implications of optimizations on stack > introspection/reflection/modification? Such as if you introspect and change > a variable in the stack through introspection (maybe for a debugger)? I > suppose it depends what level of changes are allowed. Probably simpler to > revert to a non-optimized version of the code. I'm not very familiar with > these details. > Yes, that's one source of problems. Reverting the code isn't a solution, because thread A can be introspecting while thread B is running the inner loop. You could think about introducing safe points, but this would defeat debugging, which is one of the key motivations for introspection. You could also think about exposing the length of the vector in the type of the reference (e.g. through NAT kind), which solves *this* case, but not other closely related problems. > > If it's a structured increment loop (1 to 10 by n), it seems easy to hoist >>> the range check and inline/unroll. >>> >> I agree that it *seems* easy. Unfortunately, the operative word here is >> "seems". One of the hard parts of optimization is making sure that you've >> captured all of the preconditions for the optimization to be correct. In >> this case, a subtle set of non-local precondition requirements are getting >> in the way. >> > > Since I reject this notion of concurrent field-changes mucking with my > loops, I'm curious if there are other things getting in the way. > Since I reject the notion that I am answerable to gravity, I'm curious if anything else gets in the way of me flying unaided. :-) Jokes aside, I'm sympathetic with the idea that we should just simplify the runtime. Unfortunately, from an audience uptake perspective, I think that ship has sailed. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
