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