Passing the size to free is currently in a C++14 proposal [1]. It's pretty useful (makes free no slower, might make it faster) and in most code, the size is available on free. I'm not sure it would should be mandatory, but it's definitely useful.
[1] http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3536.html On Wed, Apr 2, 2014 at 3:13 PM, comex <com...@gmail.com> wrote: > On Wed, Apr 2, 2014 at 12:25 PM, Daniel Micay <danielmi...@gmail.com> > wrote: > > Without a size parameter to `free`, an allocator needs to track the size > > of allocations manually. It increases the memory overhead, along with > > adding bookkeeping overhead. > > Not by very much... If a chunk's header is stored externally, like > tcmalloc and Linux slub, there is virtually no memory overhead at the > cost of free involving a quick hash table lookup on the address; if > it's stored internally, like jemalloc, the overhead is just possibly > some page-size-remainder wastage, and free just masks the pointer. > Either way, if chunks are ever going to be freed, you need some kind > of header to count free slots. > > I guess knowing the size would help the fast path for free be really > simple and even inlined, since it could just swap a fixed thread-local > variable. But is that really worth hanging language features on, one > way or the other? > _______________________________________________ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -- Clark. Key ID : 0x78099922 Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
