FileHandle's readData(ofLength:), as well as Data's withUnsafeBytes(), generate autoreleases on systems that feature the Objective-C bridge. If these are used in a loop to read a very large file, this can quickly consume all of the system's memory and render the machine unresponsive, for reasons that are not clear to a new developer unfamiliar with Objective-C and its pitfalls. It's also annoying to work around since an @autoreleasepool attribute can't simply be tacked onto a loop; instead, you must individually wrap every call that creates or accesses the data, or else flow control constructs such as 'break' and 'continue' become unavailable.
I am not certain we can change the behavior of the objective-c classes since it would mean a runtime behavior difference. Does this particularly express here because the ARC optimization of autorelease return values is not happening? Or is it the lifespan caused by an autorelease caused by swift?
It definitely needs more detailed traces to isolate the offenders.
I assumed it was coming from somewhere inside the MRC code of the frameworks, which is why I pitched adding autoreleasepool wrappers to the overlay. I was asked to file a bug report instead, and so here we are.
Looking at these traces, we might be getting a little of both:
I'm sure that there are many Cocoa classes that do this; however, FileHandle and Data were voted by their respective high school classes as most likely to chew through gigabytes of data in a loop, so I figured they'd be good starting points.