<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Sep 7, 2017, at 5:17 PM, Jordan Rose &lt;<a href="mailto:jordan_rose@apple.com" class="">jordan_rose@apple.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Sep 7, 2017, at 17:09, Andrew Trick &lt;<a href="mailto:atrick@apple.com" class="">atrick@apple.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Sep 7, 2017, at 2:29 PM, Jordan Rose &lt;<a href="mailto:jordan_rose@apple.com" class="">jordan_rose@apple.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><div class=""><br class="Apple-interchange-newline">We do want the Swift memory model to be consistent with the reality that on most platforms, we need the runtime to track block size.</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">I don't know where this comes from. If you don't need to be malloc-compatible, you don't strictly "need" this information. (It would break tools like 'leaks', though.)</div></div></div></blockquote><div class=""><br class=""></div><div class="">There are two distinct but related issues (1) malloc compatibility (2) malloc/free like functionality. I know developers sometimes expect or want #2. Realistically, we will always want the runtime to provide malloc_size, even if it’s not super fast, so we’re not giving up anything long term by providing #2. The fact the #1 is also a likely goal on major platforms just reinforces that position.</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">I don't understand why "realistically, we will always want the runtime to provide malloc_size". Could you explain why?</div></div></div></div></blockquote><div><br class=""></div>The standard library already makes good use of malloc_size. More to the point, I think “realistically" it needs to be possible to write tools for memory analysis and debugging. I meant “always” in the temporal sense. I don’t think all memory needs this, only memory that is directly under the user’s control.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div class="">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?</div></div></div></div></blockquote></div><br class=""><div class="">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.</div><div class=""><br class=""></div><div class="">-Andy</div></body></html>