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

FROM : John Engelhart
DATE : Fri Feb 08 05:23:00 2008

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.