3 ms·

If your program is allocating so much that you can exhaust a 64bit counter, you have a seriously bad program plus a serious memory leak. Exhausting the counter

If your program is allocating so much that you can exhaust a 64bit counter, you have a seriously bad program plus a serious memory leak. Exhausting the counter would be the least of your worries. Practically speaking you could never allocate memory that fast, a memory allocation is going to be well over 1000ns on average. Then there's the little matter of address space. Pointers on x64 are limited to 47 bits, meaning that if even you had a magical memory allocator with no book-keeping overhead, and all your allocations were 1 byte, you'd run out of pointers first. The actual virtual memory space is limited further on many operating systems, but you're still always going to be well short of 64bits.

dmytrish 3y ago
Memory is meant to be reused, "64 bit counter will be enough for everybody" is not how systems programming works.
- nyanpasu64 3y ago
  > "64 bit counter will be enough for everybody" is not how systems programming works. Except when it is: https://threatpost.com/another-linux-kernel-bug-surfaces-allowing-root-access/137800/ https://threatpost.com/another-linux-kernel-bug-surfaces-all..., fix at https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/mm/vmacache.c?id=7a9cdebdcc17e426fb5287e4a82db1dfe86339b2 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
  - hinkley 3y ago
    VMAs sound expensive. Of course a 64 bit counter is going to work for moderately expensive things. If you have a multithreaded app doing a lot of communication, that's going to be a lot of cheap allocations happening very fast. Reducing GC and allocation overhead results in more allocations being done, and pushback against ever-expanding allocation behavior is more of a challenge. Instead of ten other things being a higher priority than judicious data architecture, it's dozens or more.
- slashdev 3y ago
  Except when it is. You'd be surprised what systems programming looks like. Reference counts are not re-used when memory is re-used. And again, even if for some reason you had a global 64bit counter that you incremented on every allocation and never decremented, and you could somehow handle a billion allocations per second, you'd have 585 years before that counter overflowed back to 0. No computer or program can run for that long.

dmytrish 3y ago

Memory is meant to be reused, "64 bit counter will be enough for everybody" is not how systems programming works.

nyanpasu64 3y ago
> "64 bit counter will be enough for everybody" is not how systems programming works. Except when it is: https://threatpost.com/another-linux-kernel-bug-surfaces-allowing-root-access/137800/ https://threatpost.com/another-linux-kernel-bug-surfaces-all..., fix at https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/mm/vmacache.c?id=7a9cdebdcc17e426fb5287e4a82db1dfe86339b2 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
- hinkley 3y ago
  VMAs sound expensive. Of course a 64 bit counter is going to work for moderately expensive things. If you have a multithreaded app doing a lot of communication, that's going to be a lot of cheap allocations happening very fast. Reducing GC and allocation overhead results in more allocations being done, and pushback against ever-expanding allocation behavior is more of a challenge. Instead of ten other things being a higher priority than judicious data architecture, it's dozens or more.
slashdev 3y ago
Except when it is. You'd be surprised what systems programming looks like. Reference counts are not re-used when memory is re-used. And again, even if for some reason you had a global 64bit counter that you incremented on every allocation and never decremented, and you could somehow handle a billion allocations per second, you'd have 585 years before that counter overflowed back to 0. No computer or program can run for that long.