On Sep 11, 2013, at 10:38 , John McCall <rjmcc...@apple.com> wrote: >> [reduced need for Café Macs dinner tickets] > > Fortunately. :)
But you do know where to get them anyway…? ;-) >> [inline reference counts] > > > Right. ARC doesn’t replace the benefit of having an inline reference count. > I think if we could magically bless all objects with an inline reference > count without worrying about disrupting existing hard-coded object layouts, > we probably would. I can think of 3 ways, which you obviously never have thought of yourselves, because you guys just don’t bother with that sort of thing... *g*: 1. Non-fragile ivars, just insert one where you want it Problem there is probably that ivars aren’t as non-fragile in practice as we’d like. In addition, a whole word might be a bit much, especially when you already have an inline refcount tucked away somewhere else. 2. IV() trick Just tack it on at the end of each object that wants one…problems with class-size not reported correctly (we’re looking at you, CoreFoundation) and custom allocs. 3. 3 bits in the class pointer Since we aren’t allowed to get the isa pointer directly these days anyhow, that means we can mask out the low-order bits in object_getClass(), objc_msgSend() and the non-fragile ivar access code..hhmmm. Number of bits depends on whether you just rely on alignment or also grab what’s there from malloc() bucketing (probably shouldn’t). The “Getting Reference Counting Back into the Ring” paper claims that with 3 bits of recount, you avoid overflow for > 95% of objects, so that would be pretty good. Of course, automagic isn’t necessarily a requirement, so my favorite is: 4. Do it yourself assistance How about a function that takes a pointer to wherever I stashed my reference count and did all the right things, for example wrt. weak references? Or a macro. Did I mention this one’s my favorite? > [opting local variables out of ARC using __unsafe_unretained] > Absolutely. We’ve found that it usually doesn’t take very many > __unsafe_unretained annotations to eliminate most regressions. There are a > ton of places where any human reading the code would immediately realize that > an object won’t get released, but ARC can’t quite prove that, usually because > there’s an intervening message send. There’s a bunch of interesting research again on region analysis and proving things statically, now that the practical limitations of copying collectors are becoming more widely appreciated (see also all the off-heap stuff going on in Java-land). Rust is also interesting the way it puts in some programmer involvement in declaring intent, but then helps with making sure that this intent isn’t violated. > Most of those places don’t detectably affect performance; it’s the one or > two that happen in a loop and therefore trigger 40,000 times that you notice. > But by the same token, those sites tend to show up in Instruments and so are > easy to track down and fix. The joys of a nice skewed profile. Ahhh…. :-) Of course, the ones you don’t notice, the flat profiles, are in some ways more insidious, as they drag everything down just a bit. Along with all the other things that drag everything down a bit, and soon enough you have something that’s 10% or 2x or 10x slower than it needs to be and no obvious culprits. Cheers, Marcel _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
