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?
Yes, allowing the user to tag variables not-to-be-optimized is
probably the most straightforward solution, although it still leaves
open the possibility of programmers making a mistake. A more
convenient solution from the programmer's point of view would be to
make the "not optimize" property part of the class, and declare
NSData* with the "not optimize" property, along with the handful of
other classes that can return pointers to C storage. However, since
this would result in all NSData* objects hanging around for the life
of a routine, it might be subject to the same objections.
Having the programmer specify explicitly is undoubtedly the most
efficient way to handle it. If the programmer is to be responsible,
I'd at least like to see a compiler warning whenever "bytes" is called
on an NSData object while GC is on.
- Dennis D.
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