> On Jul 14, 2017, at 4:31 PM, Charles Srstka <cocoa...@charlessoft.com> wrote:
>> On Jul 14, 2017, at 3:24 PM, John McCall <rjmcc...@apple.com
>> <mailto:rjmcc...@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
