On Thu, Sep 10, 2009 at 9:33 AM, Jens Alfke <email@hidden> wrote:
>
> On Sep 10, 2009, at 8:41 AM, Clark Cox wrote:
>
>> Yes, this can have unfortunate
>> side-effects for the Obj-C GC in MacOS X; No, this is not an issue of
>> GCC/clang not conforming to 6.2.4.
>
> I agree this isn't a conformance issue, but the GC side effects are worth
> focusing on, regardless. I haven't run into them myself, but I haven't
> developed any really major apps with GC yet (just my Mercurial client
> Murky.)
>
> Off-list I suggested to an Apple engineer that the compiler should avoid
> optimizing away stack storage of local variables that point to Obj-C
> objects, when GC is enabled. The response was that this had been
> investigated but led to too much heap growth (i.e. too many actual garbage
> objects being held onto by unused local variables.)
>
> Not sure what else to suggest. It seems there needs to be a way to
> explicitly mark that you're keeping a reference to an object, since
> declaring a local variable pointing to it isn't sufficient. Maybe some sort
> of "__dont_optimize_away" annotation on the local variable?
I would rather see the collector API provide the ability to associate
a pointer "B" with another pointer "A" such that as long as "B" or "A"
are found in a collector scannable location then storage related to
"A" will continue to exist.
If this ability existed then NSData could mark the pointer it vends
via -bytes as related to the pointer to the NSData instance itself. As
long as you stored the pointer you get from bytes in a scannable
location (use in code block would by definition be in a scannable
location) then bytes would remain valid because NSData instance
backing that storage continues to exist.
The optimizer doesn't know about GC and IMHO it should never need to
know. The compiler of course does need to inject barriers as needed
but that is done before the optimizer.
-Shawn
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Objc-language mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
