> On Sep 7, 2017, at 5:56 PM, Jordan Rose <jordan_r...@apple.com> wrote:
>
>
>
>> On Sep 7, 2017, at 17:46, Andrew Trick <atr...@apple.com
>> <mailto:atr...@apple.com>> wrote:
>>
>>
>>> On Sep 7, 2017, at 5:40 PM, Joe Groff <jgr...@apple.com
>>> <mailto:jgr...@apple.com>> wrote:
>>>
>>>
>>>>
>>>>> But then given that, I don't understand why the 'capacity' parameter is
>>>>> necessary. Under what circumstances would it actually be faster than
>>>>> "just" calling malloc_size?
>>>>
>>>> The runtime may need to hash the address or traverse a lookup table to
>>>> find out which allocation pool the block resides in. Now, that’s only if
>>>> some platform ditches full malloc compatibility for user allocations, so
>>>> I’m not sure how realistic it is.
>>>
>>> It seems to me that you could still provide malloc/free compatibility with
>>> a zone that had to do a relatively expensive traversal on free() to recover
>>> the pool the memory came from; malloc/free just wouldn't be the ideal
>>> interface in that situation.
>>>
>>> -Joe
>>
>> Joe is right, and I just learned how amazing malloc zones are.
>
> As long as you support multiple allocators (or hide everything behind
> malloc/free), there's already a cost of malloc_zone_from_ptr or equivalent.
> Without seeing a concrete use case, I wouldn't want to stay with the
> harder-to-use API in UnsafePointer itself. It might be a feature of a
> particular allocator that you need to keep the capacity around, but it isn't
> something generally true about Swift's memory model, and probably never will
> be.
>
> (Interesting reference points: malloc/malloc.h and the implementation of
> malloc on macOS
> <https://opensource.apple.com/source/libmalloc/libmalloc-116.50.8/src/malloc.c.auto.html>
> - search for "free(void *ptr)".)
>
> Jordan
I’m primarily arguing from the point of view that UnsafeBufferPointer should
pass it’s deallocation capacity and should be implementable in terms of
UnsafePointer. But I’m fine hiding the capacity argument from the public API
for now. We know what the proposal author wants to do, so unless Joe still
feels strongly, we could accept the proposal as-is, put the API decision to
rest and focus on better documentation and and assertions.
-Andy
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
