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

Philippe Hausler phausler at apple.com
Fri Jul 14 15:43:22 CDT 2017

> On Jul 14, 2017, at 1:40 PM, John McCall via swift-evolution <swift-evolution at swift.org> wrote:
>> On Jul 14, 2017, at 4:31 PM, Charles Srstka <cocoadev at charlessoft.com <mailto: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.
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

Would it perhaps be reasonable for the Data backing to manually managed the storage via Unmanaged? Since we know the lifespan of the container and are the sole controllers in most places.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170714/4efca9cb/attachment.html>

More information about the swift-evolution mailing list