[Moderator] Re: Use of Mac OS X 10.5 / Leopards Garbage Collection Considered Harmful
[Moderator] Re: Use of Mac OS X 10.5 / Leopards Garbage Collection Considered Harmful
- Subject: [Moderator] Re: Use of Mac OS X 10.5 / Leopards Garbage Collection Considered Harmful
- From: Scott Anguish <email@hidden>
- Date: Fri, 8 Feb 2008 13:17:53 -0800
This discussion has gotten a bit far from involving Cocoa directly.
Please move it to the objective-C mailing list (email@hidden
).
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@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
_______________________________________________
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