[Moderator] Re: Use of Mac OS X 10.5 / Leopards Garbage Collection Considered Harmful

FROM : Scott Anguish
DATE : Fri Feb 08 22:17:53 2008

This discussion has gotten a bit far from involving Cocoa directly.

Please move it to the objective-C mailing list (<email_removed>
).


On Feb 7, 2008, at 8:23 PM, John Engelhart wrote:

>
> On Feb 6, 2008, at 10:12 AM, Michael Tsai wrote:
>

>> On Feb 6, 2008, at 4:39 AM, John Engelhart wrote:
>>

>>> Read the above, "object" is synonymous for "struct".  The "layout" 
>>> of an object is identical to the "layout" of a struct.

>>
>>
>> That is true but irrelevant. What matters for garbage collection is 
>> whether the variables are typed as objects at compile time, because 
>> that's what determines what code the compiler emits for assignments.

>
> A nitpick, but it is more correct to say "where the variables are 
> typed as __strong at compile time".  Subtle, but important, 
> especially when you consider the following from objc/objc.h:
>
> typedef struct objc_object {
>    Class isa;
> } *id;
>
> Despite any prose definition of what an object is, this is the 
> definition of an object to the compiler.  I will note that the 
> compilers definition of an object is a) a struct, and b) not 
> __strong.  Therefore, in an overly pedantically strict sense, your 
> statement is wrong, but I'm fairly sure you would have picked 
> __strong in place of objects as that is the effect you were trying 
> to communicate.
>
> Point B is especially interesting, and to fully appreciate its 
> consequences this is going to turn in to an ugly discussion of the 
> intermediate gimple code.  When you consider the points I've raised 
> from this perspective, and what's really going on under the hood, 
> many of my arguments will snap in to focus.  Needless to say, we 
> rarely examine the assembly code emitted by the compiler, and in 
> practice the effect of a write barrier assignment and a non-write 
> barrier assignment during execution is identical, you would have no 
> reason to suspect anything is wrong.
>
> One of my original claims is that, despite the prose definition of 
> how the GC system works and peoples beliefs, the compiler is 
> magically transforming some pointers in to __strong behind your back 
> by some unspecified logic, as the definition of id shows. 'id' is 
> the codified definition of an object in fact, and the fact that 
> __strong is not part of its definition means that the prose 
> definition of "objects are __strong" is misleading at best, but 
> wrong in a strict sense. And since one pointer looks pretty much 
> like any other pointer in the guts of the compiler, the likelihood 
> that this magical promotion is being applied correctly to the 
> appropriate pointers is pretty slim.  Since __strong is not being 
> treated as a type qualifier per ANSI-C rules, there is nothing in 
> place to catch inadvertent "down promotions" when they happen.  The 
> true performance impact of the GC system has probably also been 
> grossly understated as wrapping a write to memory in a function call 
> essentially obliterates any hope of hoisting values in to registers 
> during optimization along with the attendant performance robbing 
> spills.
>
> Another claim I have made is that "treating everything on the stack 
> as __strong is not the right thing, it is only going to mask the 
> problem."  One could argue that the choice of treating everything on 
> the stack as __strong is proof of how often the compiler is getting 
> this automagic promotion wrong, or otherwise dropping the __strong 
> qualification during some code transformation.  My hypothesis is 
> that if write barriers were being generated correctly, there would 
> be no need to treat the stack as special, other than the fact of 
> "how much" of the stack to be considered live relative to the top 
> frame.
>
> There has also been some discussion regarding proper use of memory 
> allocated by NSAllocateCollectable, such as its use with CFString 
> creation methods.  This highlights another point of mine.  Despite 
> the (sometimes foaming at the mouth) assertions that the GC rules 
> are "easy", what is transpiring is reasonable people are having 
> differences of opinion regarding the use of GC allocated memory. 
> They are even perfectly valid, totally reasonable interpretations. 
> This highlights that in practice, these "simple rules" are in fact 
> deceptively complex and trivially easy to get wrong.  Understand 
> that it doesn't really matter who is right in the argument, the fact 
> that there is reasonable debate about something which should be 
> completely unambiguous and crystal clear demonstrates that in 
> practice, there's probably one correct way, and many wrong ways, and 
> chances are you are going to get it wrong.  From experience, being 
> told that "you obviously should have used __strong, DUH" after four 
> days of intense debugging is going to ring hollow.  You should be 
> cautious of objects near your vicinity spontaneously levitating and 
> taking flight.  Or, as a courtesy, at least hang a sign on the door.
> _______________________________________________
>
> Cocoa-dev mailing list (<email_removed>)
>
> 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:
> http://lists.apple.com/mailman/options/cocoa-dev/<email_removed>
>
> This email sent to <email_removed>