Re: Use of Mac OS X 10.5 / Leopards Garbage Collection Considered Harmful
Re: Use of Mac OS X 10.5 / Leopards Garbage Collection Considered Harmful
- Subject: Re: Use of Mac OS X 10.5 / Leopards Garbage Collection Considered Harmful
- From: John Engelhart <email@hidden>
- Date: Thu, 7 Feb 2008 23:23:00 -0500
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@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