5 ms·

Tracing GC is not always faster. GC time is proportional to the size of the allocated memory, reference counting time is not.

• sklogic 10y ago
  Why do you even care about the GC epoch length? It does not affect the mutator performance at all. EDIT: actually, it does a bit: the longer the epoch, the better, because at the end of the epoch a short stop-the-world is required to collect the global roots from registers and stacks.
  • jules 10y ago
    It doesn't affect mutator performance, until it does, and your program grinds to a halt for several seconds.
    • sklogic 10y ago
      > until it does How exactly? > grinds to a halt for several seconds What? Stop-the-world in the realtime collectors is always for a set duration, only to scan the registers and tops of the stacks (if there are any stacks at all, stackless implementations have even a better latency).
      • jules 10y ago
        > How exactly? Heap fills up, you need a full collection. During that collection your program is running and allocating, but runs out of space, so it grinds to a halt. Look, there is a reason why Rust is a thing, why realtime collectors are only used in niche cases, why there are people whose sole job is to fix GC issues, why there are people programming in Java/C# very carefully to ensure that a full heap collection never happens, etc. GC isn't a magic bullet.
        • sklogic 10y ago
          > During that collection your program is running and allocating, but runs out of space, so it grinds to a halt. It's a marginal case that should never happen, just like the case of running out of memory altogether. And RC will behave even worse in such a case. Also, all three parts are running concurrently - marker, sweeper and mutator. Sweeper is constantly supplying the mutator with the new free cells from the current epoch, so you don't need to wait for another epoch to start getting new free cells.
          • jules 10y ago
            It's not about running out of memory altogether, it's about the heap filling up with dead objects while the GC doesn't yet know that they are dead. Of course things are great when they are great and the GC can keep up with the mutator. Yet failure does happen whether or not you think it should happen, hence all the efforts that I mentioned that are trying to fix the issues.
            • sklogic 10y ago
              As I said, in such a case RC would behave even worse.
              • jules 10y ago
                Yes, you made that assertion.
                • sklogic 10y ago
                  This is not an assertion, it is a practical observation.
• pjmlp 10y ago
  Reference counting time is proportional to data structure sizes on deletion. You can get a "stop the world" effect with a cascade set of references reaching zero.
  • the_mitsuhiko 10y ago
    > Reference counting time is proportional to data structure sizes on deletion. The actual garbage collection in all collectors is proportional to the amount of data that needs to be deleted. There are plenty of implementations of refcounting where the data is pushed into a freelist or cleaned up deferred.
    • pjmlp 10y ago
      At which point you start making RC behave more like tracing collectors, so why not start with them in first place? Also there are generational tracing compacting collectors with (almost) no pauses, so I doubt such approach wins over them when measuring performance and fragmentation across application usages.
    • chrismonsanto 10y ago
      > The actual garbage collection in all collectors is proportional to the amount of data that needs to be deleted. This is false, copying GC is a simple counterexample