> On May 3, 2017, at 12:05 AM, Paul Cantrell via swift-evolution > <[email protected]> wrote: > I like the spirit of the proposal. It leaves me a bit uneasy because the > practical ramifications are difficult to fully anticipate. Here follow some > questions / concerns for the proposal authors. > > (Apologies if these were answered somewhere deep in a discussion thread; it’s > the end of the semester and I’ve not kept up with the list.) > > • • • > > First, have you done any systematic exploration of how impactful this rule > is? The proposal states in several places that it hopes/expects violations > will be rare, but is that empirical or speculative?
Initially, it was just well-informed speculation, but we're gathering more and more evidence that it's borne out in practice. Even large code bases have at most a couple of static violations, and that's before we've implemented some of the refinements around struct properties. > I tried playing around with the implications, thought I’d found a problematic > example by writing an in-place Array.shuffle() method — and then was pleased > to realize that the proposal already covered my example with swapAt(). In > half an hour, I couldn’t come up with something the proposal disallows that > it clearly should allow. > > Still, the implications of a rule like this are difficult to anticipate. It > would be interesting to know how many errors it flags in the Swift source > compatibility suite, for example. Is that something we could do before going > all-in on a fully robust implementation? That is definitely an experiment we're running. Unfortunately, we can only test for static violations with this, because checking for dynamic violations requires execution tests. > Second, what are the performance implications of dynamic exclusivity > enforcement? Introducing overhead to something as basic as variable access > seems dicey. Will it kill “C-like” performance for object properties? For > closure vars? It will definitely add overhead to class member access, global variable access, and closure access. Optimization may be able to reduce those overheads; for example, we can look at every use of a private property and often quickly prove that it is impossible to have an access violation on it. (That can be extended to internal properties in WMO builds; it is impossible for open properties.) > Will “accesses underway” flags add to the memory footprint of every object & > every closure? We were initially considering the use of "access underway" flags, but eventually decided that it made more sense to use a separate global tracking system. Currently this table is thread-local, and we expect it to be small enough at any given time that a linear scan will perform acceptably. (In your experiments, you've no doubt observed that it takes some effort to actually get an access to be non-instantaneous.) > You write that your “hope is that…dynamic access-tracking [will be] cheap > enough to enable by default;” have you proved this out with a prototype > implementation yet? This is underway. > Or maybe this check is disabled in optimized builds, and I’m fussing over > nothing? That is something we're considering. To quote from a different reply (that I just made, you haven't missed anything): One direction we're exploring for dynamic enforcement is enabling it only in certain builds by default (e.g. debug configurations). Unlike array bounds checks and integer overflows, exclusivity violations are generally not data-dependent: it's usually true that just executing the code in any configuration will adequately test for dynamic exclusivity violations. You can get them with races, of course, but the dynamic enforcement mechanisms we're looking at will probably not detect cross-thread violations anyway. Of course, you can make a reasonable argument that not enabling dynamic enforcement checks in production builds would contradict Swift's general policy of "safe by default", so this is not a certain thing. We would very much like to hear swift-evolution's thoughts about this. John. > > Cheers, > > Paul > > >> On May 2, 2017, at 3:07 PM, Ben Cohen <[email protected] >> <mailto:[email protected]>> wrote: >> >> Hello Swift community, >> >> The review of SE-0176: "Enforce Exclusive Access to Memory" begins now and >> runs through May 8, 2017. >> >> The proposal is available here: >> >> https://github.com/apple/swift-evolution/blob/master/proposals/0176-enforce-exclusive-access-to-memory.md >> >> <https://github.com/apple/swift-evolution/blob/master/proposals/0176-enforce-exclusive-access-to-memory.md> >> Reviews are an important part of the Swift evolution process. All reviews >> should be sent to the swift-evolution mailing list at: >> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> or, if you would like to keep your feedback private, directly to the review >> manager. >> >> When replying, please try to keep the proposal link at the top of the >> message: >> >> Proposal link: >> >> https://github.com/apple/swift-evolution/blob/master/proposals/0176-enforce-exclusive-access-to-memory.md >> >> <https://github.com/apple/swift-evolution/blob/master/proposals/0176-enforce-exclusive-access-to-memory.md> >> Reply text >> >> Other replies >> >> <https://github.com/apple/swift-evolution#what-goes-into-a-review-1> >> What goes into a review? >> >> The goal of the review process is to improve the proposal under review >> through constructive criticism and, eventually, determine the direction of >> Swift. When writing your review, here are some questions you might want to >> answer in your review: >> >> What is your evaluation of the proposal? >> Is the problem being addressed significant enough to warrant a change to >> Swift? >> Does this proposal fit well with the feel and direction of Swift? >> If you have used other languages or libraries with a similar feature, how do >> you feel that this proposal compares to those? >> How much effort did you put into your review? A glance, a quick reading, or >> an in-depth study? >> More information about the Swift evolution process is available at: >> >> https://github.com/apple/swift-evolution/blob/master/process.md >> <https://github.com/apple/swift-evolution/blob/master/process.md> >> >> Thanks, >> Ben Cohen >> Review Manager >> >> _______________________________________________ >> swift-evolution-announce mailing list >> [email protected] >> <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution-announce >> <https://lists.swift.org/mailman/listinfo/swift-evolution-announce> > > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
