[swift-evolution] Pitch: Wrap calls to NSFileHandle and NSData in autorelease pools

[John McCall]

> On Jul 14, 2017, at 4:31 PM, Charles Srstka <cocoadev at charlessoft.com> wrote:
>> On Jul 14, 2017, at 3:24 PM, John McCall <rjmccall at apple.com <mailto:rjmccall at apple.com>> wrote:
>> 
>> We should absolutely not need to do the later autoreleases.  We have logic to autorelease objects when calling returns-inner-pointer objects on them, but we shouldn't need to do that in safe patterns like what Data does here by scoping the pointer to the closure.  We probably just don't actually have a way to turn that logic off, i.e. an equivalent of objc_precise_lifetime in ObjC ARC.
>> 
>> I have no idea why the first autorelease wouldn't be reclaimed.  There's a well-known issue with micro-reductions involving autoreleases on x86, where the first autorelease from the executable doesn't get reclaimed because the dynamic linker's lazy-binding stub interferes somehow.  Can you verify that you still see that initial autorelease on subsequent Data creations?
> 
> Changing the loop to run five times, I end up with five NSConcreteDatas in Instruments. For the first one, I get the initial autorelease in -[NSConcreteFileHandle readDataOfLength], as well as the subsequent 32,768 autoreleases (it actually seems to be one autorelease per every 32 bytes in the data; if I adjust the buffer size the number of autoreleases changes accordingly). 
> 
> For the other four… it looks exactly the same, actually. :-/
> 
> Instruments .trace file is available off-list by request.

Would you mind just filing a bug with a reduced test case?

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170714/6da7d0ab/attachment.html>