<div dir="ltr"><div>let me summarize why i think deallocate should lose the capacity parameter for now:<br><br></div><ul><li>up to now, the capacity argument has been poorly, even misleadingly documented. this means it is unlikely that existing users of the API are using it correctly. </li><li><span style="font-family:monospace,monospace">deallocate(capacity:)</span> allows for optimizations that could improve the performance of the Swift heap. however, these optimizations are not in place yet, nor will they be any time soon, so dropping the parameter would result in no performance regressions.<br></li><li>users coming from C/C++ are used to the <span style="font-family:monospace,monospace">malloc(_:)</span> – <span style="font-family:monospace,monospace">free()</span> pattern. Swift should support this both for learnability, and for <span style="font-family:monospace,monospace">malloc</span>-compatibility. <br></li><li>completely departing from the <span style="font-family:monospace,monospace">malloc</span> memory model might save a few bytes of headers in the heap, but as discussed in this thread, there are other upsides of Swift being <span style="font-family:monospace,monospace">malloc</span>-compatible.<br></li><li>there is nothing preventing us from reintroducing <span style="font-family:monospace,monospace">deallocate(allocatedCapacity:)</span> in the future, once the runtime actually supports this feature. informed users looking for a performance boost could opt-in to use this API instead. <br></li><li>deprecating, and then un-deprecating <span style="font-family:monospace,monospace">deallocate(capacity:)</span> might sound extra, but keeping this method unbothered is actually a bad idea. whoever is using it right now, is probably not using it correctly. The best strategy is to reintroduce it later as a well-documented <i>opt-in</i> feature. Grandfathering in old incorrect code offers no benefits and many problems. <br></li><li>lying to users is never a good idea. for the forseeable future, <span style="font-family:monospace,monospace">Heap.cpp</span> calls <span style="font-family:monospace,monospace">free()</span>, and Swift shouldn’t pretend like it supports something it doesn’t support. <br></li></ul><br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 7, 2017 at 8:18 PM, Andrew Trick <span dir="ltr">&lt;<a href="mailto:atrick@apple.com" target="_blank">atrick@apple.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div class="h5"><br><div><blockquote type="cite"><div>On Sep 7, 2017, at 5:56 PM, Jordan Rose &lt;<a href="mailto:jordan_rose@apple.com" target="_blank">jordan_rose@apple.com</a>&gt; wrote:</div><br class="m_666510761822654457Apple-interchange-newline"><div><div style="word-wrap:break-word;line-break:after-white-space"><br><div><br><blockquote type="cite"><div>On Sep 7, 2017, at 17:46, Andrew Trick &lt;<a href="mailto:atrick@apple.com" target="_blank">atrick@apple.com</a>&gt; wrote:</div><br class="m_666510761822654457Apple-interchange-newline"><div><div><br><blockquote type="cite">On Sep 7, 2017, at 5:40 PM, Joe Groff &lt;<a href="mailto:jgroff@apple.com" target="_blank">jgroff@apple.com</a>&gt; wrote:<br><br><br><blockquote type="cite"><br><blockquote type="cite">But then given that, I don&#39;t understand why the &#39;capacity&#39; parameter is necessary. Under what circumstances would it actually be faster than &quot;just&quot; calling malloc_size?<br></blockquote><br>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.<br></blockquote><br>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&#39;t be the ideal interface in that situation.<br><br>-Joe<br></blockquote><br>Joe is right, and I just learned how amazing malloc zones are.<br></div></div></blockquote><br></div><div><div>As long as you support multiple allocators (or hide everything behind malloc/free), there&#39;s already a cost of malloc_zone_from_ptr or equivalent. Without seeing a concrete use case, I wouldn&#39;t want to stay with the harder-to-use API <i>in UnsafePointer itself.</i> It might be a feature of a <i>particular</i> allocator that you need to keep the capacity around, but it <i>isn&#39;t</i> something generally true about Swift&#39;s memory model, and probably never will be.</div><div><br></div><div>(Interesting reference points: malloc/malloc.h and <a href="https://opensource.apple.com/source/libmalloc/libmalloc-116.50.8/src/malloc.c.auto.html" target="_blank">the implementation of malloc on macOS</a> - search for &quot;free(void *ptr)&quot;.)</div><div><br></div></div>Jordan</div></div></blockquote><br></div></div></div><div>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.</div><div><br></div><div>-Andy</div></div></blockquote></div><br></div>