> On Sep 7, 2017, at 11:55 AM, Taylor Swift <kelvin1...@gmail.com> wrote: > > > > On Thu, Sep 7, 2017 at 12:31 PM, Andrew Trick <atr...@apple.com > <mailto:atr...@apple.com>> wrote: > >> On Sep 7, 2017, at 8:06 AM, Taylor Swift <kelvin1...@gmail.com >> <mailto:kelvin1...@gmail.com>> wrote: >> >> I don’t see any source for this claim in the documentation >> <https://developer.apple.com/documentation/swift/unsafemutablepointer/2295090-deallocate>, >> or the source code >> <https://github.com/apple/swift/blob/master/stdlib/public/core/UnsafePointer.swift.gyb#L432>. >> As far as I can tell the expected behavior is that partial deallocation >> “should” work. >> >> On Thu, Sep 7, 2017 at 8:59 AM, Joe Groff <jgr...@apple.com >> <mailto:jgr...@apple.com>> wrote: >> >> The segfaulting example is an incorrect usage. The only valid parameters to >> deallocate(capacity:) are the base address of an allocation, and the >> original capacity passed into allocate(); it has never been intended to >> support partial deallocation of allocated blocks. It seems to me like this >> proposal is based on a misunderstanding of how the API works. The >> documentation and/or name should be clarified. >> >> -Joe >> >> > “fixing” this bug will cause programs that once operated on previously >> > valid assumptions of “free()” semantics to behave differently, without any >> > warnings ever being generated. Conversely incorrect code will suddenly >> > become “correct” though this is less of a problem. >> > >> >> A sized implementation may fail more obviously when you violate the >> >> contract in the future. Not having sized deallocation is a known >> >> deficiency of the C model we've been fairly diligent about avoiding in >> >> Swift's allocation interfaces, and it would be extremely unfortunate for >> >> us to backpedal from it. >> >> >> >> -Joe > > This discussion needs to be grounded by reiterating role of the API. > UnsafePointer specifies the memory model without extraneous functionality or > convenience. > > The UnsafePointer.deallocate() API *is not*: > > - a common, expected, or encouraged way to deallocate > > - the simplest, safest, or most convenient way to deallocate > > - necessarilly the most optimal path for deallocation > > There is only one decision that needs to be made here. Does the Swift runtime > track allocation size for manually allocated blocks? I think the answer > should be "yes", or at least haven't heard a strong argument against it. > UnsafePointer.deallocate() needs to direcly reflect that model by making > `allocatedCapacity` an *optional* argument. > > Discussion about whether this API is unsafe, misleading, suboptimal or > incorrectly implemented are secondary. Those are all deficiencies in the > current documentation, current implementation, and availability of > higher-level APIs. > > Note that yesterday I argued that an optional argument wasn't worth the > potential for confusion. That's true from a practical perspective, but I had > lost sight of need to clearly specify the memory model. We want the Swift > runtime to both have the functionality for tracking block size and also allow > user code to track it more efficiently. Both those intentions need to be > reflected in this API. > > -Andy > > idk how the swift heap is planned to be implemented, but why is passing the > capacity to deallocate considered the fast path anyway? i thought the block > size was stored in a header right before the block pointer
It doesn't have to be. When all allocation and deallocation calls carry matching capacity values, then that overhead can be eliminated when allocating out of a heterogeneous heap. Optimized allocators also generally have per-thread pools for common allocation sizes, and if you have the capacity value on hand, it can be quickly matched to the right pool size, and constant allocation sizes can potentially be recognized by the compiler and turned into allocator calls that directly allocate out of a specific pool. -Joe
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
