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: Greg Parker <email@hidden>
- Date: Fri, 8 Feb 2008 00:17:59 -0800
John Engelhart wrote:
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.
No, it isn't. The Objective-C compiler has implicit knowledge of id,
with or without the definition in objc.h. It knows `id` is always
__strong, it knows `id` can be implicitly converted to other object
types without a warning, etc. Pretend that the definition of `id` seen
there is for the benefit of plain C code.
For example, this program (which contains no C definition of `id`)
compiles successfully with the Objective-C compiler.
% cat test.m
/* no #includes here */
int main() {
id object;
return (int)object;
}
% cc -Wall test.m
%
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.
The "unspecified logic" is this: all pointers of Objective-C object
types, including `id`, are implicitly __strong. (Unless they're
explicitly __weak, of course, but __weak is a whole 'nother can of
monkeys.)
This isn't hard for the compiler to do. The Objective-C compiler has
special knowledge of type `id`. It also knows perfectly well which
pointer types are object types: they're the ones spelled `@interface`
or `@class`.
Compiler bugs are always possible, of course. (For example, global
arrays of id were broken for a while during Leopard development.) If
you find any, file a bug report and we'll fix the compiler.
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 is one very good reason to treat the stack specially. In fact,
you mentioned it yourself:
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.
Precisely. Write barriers are not free. Treating the stack specially
means write barriers are never needed for local variables or
parameters. This makes it faster. The remaining writes are
sufficiently uncommon that the write barrier expense is manageable.
This is especially true when comparing with non-GC Objective-C code,
where writes to ivars and globals typically incur the overhead of
retain/release anyway.
--
Greg Parker email@hidden Runtime Wrangler
_______________________________________________
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