Thanks for your reply, Bill.
On Sat, Sep 12, 2009 at 10:43 PM, Bill Bumgarner <email@hidden> wrote:
> (2) Objects that stick around a lot longer than they should because of the
> lack of the compiler reusing their slot on the stack.
> [...]
> A particularly unfortunate form of this problem is when you have a bunch of
> pointers on the stack in func B, called by func A. B then returns and A
> calls C which promptly does 'int bunchOfStuff[100]', but doesn't zero it.
I see. But given that this is a problem (albeit a
probably-but-not-necessarily lesser one) whether or not stack slots
are re-used, wouldn't zeroing stack slots as and when reserved be the
best way to fix it?
> So, yes, externally to the interior pointer issue, that particular compiler
> optimization actually makes the collector more efficient.
I can see that requiring the programmer to nil slots they don't intend
to re-use before calling long-lived functions or methods is not really
feasible. Perhaps, indeed, the compiler should be more aggressive,
zeroing slots when it detects they are no longer used irrespective of
whether their space is yet required?! That would make the collector
more efficient and also make potential issues with slot re-use
apparent more quickly.
> (1) Deal with the handful of methods that return C pointers. This has
> actually largely been dealt with via declarations like:
>
> - (__strong const char *)UTF8String; // Convenience to return
> null-terminated UTF8 representation
Indeed.
> (2) Deal with the whole NSData/bytes debacle
>
> Some kind of annotation may be required as per suggestions like the above.
I hope to see this sometime soon!
> (3) Deal with the *p++ type problem.
>
> This is more difficult. In particular, it matters if p was allocated in
> scanned or unscanned memory. Care also has to be taken when potentially
> colluding runtime & compile time behavior. For example, the compiler
> should not be taught about -bytes or NSData or NSAllocateCollectable, even.
Do you already have a simple "don't alter a base pointer if it's
marked __strong" rule?
Thanks,
H
_______________________________________________
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
