3 ms·

GC is a tricky problem. Even when you have a system that performs GC in the background (like Java has been doing for almost 10 years) you still are susceptible

• jshen 15y ago
  I rarely complain about someones english, but that link is very hard to read. "Key point of generational GC is what it does need to collect entire heap each time, but just portion of it (e.g. young space)." "This principle is based on hypnotize that most object “die young”, i.e. majority of objects are becoming garbage shortly after being allocated."
• eru 15y ago
  > you still are susceptible to your heap becoming fragmented and run the risk of requiring a full GC to compact the heap. But isn't the heap fragmentation a much bigger problem with malloc style memory management?
  • tedunangst 15y ago
    No, because you can allocate from different arenas if you need to. Using plain malloc may lead to fragmentation, but there's no law requiring you to use a single lowest common denominator allocator for your entire program.
    • fpgeek 15y ago
      That doesn't contradict his observation. Changing your program to use custom memory allocators can solve fragmentation issues, but that's a much bigger step than the changes required to avoid too many (or too expensive ) full GCs (i.e. tuning the garbage collector directly, gettting "permanent" data out of the garbage-collected heap, minimizing mutations so there's less to scan...).
      • tedunangst 15y ago
        The only times I've had difficulty solving a fragmentation problem was because a GC was involved, and rewriting the code in an effort to trick some enormous black box into doing what I wanted was a lot more difficult than just writing code that did what I wanted in the first place. ymmv.
        • eru 15y ago
          I guess in theory fpgeek is right, and his great-grandparent post is in the vein of what I thought of answering. But I guess in practice tedunangst is more right at the moment. I'll welcome better garbage collection.