> On Jul 14, 2017, at 3:24 PM, John McCall <[email protected]> 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. Charles
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
