Re: ARC vs Manual Reference Counting
Re: ARC vs Manual Reference Counting
- Subject: Re: ARC vs Manual Reference Counting
- From: John McCall <email@hidden>
- Date: Fri, 13 Sep 2013 10:55:02 -0700
On Sep 13, 2013, at 3:04 AM, Marcel Weiher <email@hidden> wrote:
> On Sep 11, 2013, at 10:38 , John McCall <email@hidden> wrote:
>>> [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.
Right, both of these are very difficult because of widespread code that assumes things about the layout of objects. Also, adding extra fields to objects could easily push them over allocation quanta. It’s a hard problem.
> 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.
We’ve certainly looked into things like this.
> 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?
You’re certainly welcome to file a radar asking for an SDK feature like that if you haven’t already.
>> [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.
The trouble is that Objective-C is essentially immune to non-heuristic static analysis, not just formally but in practice as well. People can and do dynamically add and replace methods on classes, use isa swizzling to change the class of an existing object, and so on, all of which individually make interprocedural region analysis impossible.
>> 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.
Yes, this is definitely a problem, and an unsolvable one at that.
John.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden