> On Sep 7, 2017, at 5:34 PM, Andrew Trick <atr...@apple.com> wrote: > >> >> On Sep 7, 2017, at 5:17 PM, Jordan Rose <jordan_r...@apple.com> wrote: >> >> >> >>> On Sep 7, 2017, at 17:09, Andrew Trick <atr...@apple.com> wrote: >>> >>> >>>> On Sep 7, 2017, at 2:29 PM, Jordan Rose <jordan_r...@apple.com> wrote: >>>> >>>>> >>>>> 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. >>>> >>>> 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.) >>> >>> 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. >> >> I don't understand why "realistically, we will always want the runtime to >> provide malloc_size". Could you explain why? > > 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. > >> 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 _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
