> On Sep 7, 2017, at 17:09, Andrew Trick <[email protected]> wrote: > > >> On Sep 7, 2017, at 2:29 PM, Jordan Rose <[email protected] >> <mailto:[email protected]>> 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? 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? Jordan > >>> If our memory model states that the runtime tracks capacity of manually >>> allocated blocks, then the deallocation capacity should be optional to >>> reflect that. >>> >>> Still waiting to hear any arguments that something about that memory model >>> is bad. >> >> I don't see an advantage to having the parameter if we're going to promise >> that it's always present. It is additional complexity for very little win in >> a generic interface. If someone wants to write a special allocation entry >> point that actually makes use of this, they can do so, but it shouldn't live >> on UnsafePointer. >> >> (We also have nothing that prevents you from doing `(ptr+1).deallocate()`, >> but, well, "unsafe".) > > I also don’t see any usability advantage in providing the extra argument for > anyone directly using UnsafePointer, which is why I initially objected to Joe > Groff’s request. Then I realized I care less about usability and potential > confusion than I care that UnsafePointer API can be viewed is a specification > of the Swift's basic memory management functionality. We want to communicate > that data structures doing manual allocation/deallocation should provide the > allocated capacity during deallocation if it is available. The runtime could > make good use of that. In particular, I want UnsafeBufferPointer’s > deallocate() to be able to call UnsafePointer.deallocate(allocatedCapacity: > buffer.count), rather than implementing it in terms of Builtins. > > Incidentally, FWIW, I think compiled code should continue to be required to > pass the capacity to the runtime during deallocation. That way, any changes > in the runtime implementation of deallocation, particularly extra address > checks, are isolated to the standard library.
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
