3 ms·

What about if you reach 100 billion times a second (maybe with 128 cores) and have a long running system? Maybe in this case 128-bit or 96-bit counters are bett

• jeremyjh 3y ago
  Is it even physically possible to allocate memory that fast?
• slashdev 3y ago
  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.
• nyanpasu64 3y ago
  You can't allocate and deallocate the same address (incrementing that address's generation by 1 each time) 100 billion times per second.
• Tuna-Fish 3y ago
  There is a separate counter for every memory object. One counter is only ever going to be touched by a single core at a time. And even if there was a single counter, multithreading cannot make incrementing a counter faster. Two cores cannot write to the same cache line at the same time. Instead, cache lines need to bounce across cores when you write to them, and this takes such a long time that it turns the time it takes to roll over from centuries to millennia.