8 ms·

Crazy to me that garbage collection systems are a subject of continual evolution and discussion. You'd think it would be "solved" by now... Or is that just in J

Crazy to me that garbage collection systems are a subject of continual evolution and discussion. You'd think it would be "solved" by now... Or is that just in Java world?

killingtime74 4y ago
I'm not sure what "solved" would mean for GC. Can't there always be improvements in maintainability, pause duration, correctness, throughput etc. Many dimensions to continually improve on. Unless someone comes up with a no pause, no compute power no code fully correct GC?
- kanzenryu2 4y ago
  Java already has that GC, it's called Epsilon https://blogs.oracle.com/javamagazine/post/epsilon-the-jdks-do-nothing-garbage-collector https://blogs.oracle.com/javamagazine/post/epsilon-the-jdks-...
  - Alifatisk 4y ago
    Epsilon doesn't GC at all?
    - deleted 4y ago
      [deleted]
    - kaba0 4y ago
      I think it was a tongue in cheek reply, as it is indeed a no-code, no-pause, no-compute power GC that does eventually reclaim the garbage (at process exit).
      - Alifatisk 4y ago
        Correct me if I am wrong but does it really GC at all if you receive an OutOfMemoryError?
        kaba0 4y ago
        It’s meant for short lived apps where you simply wouldn’t get OOM either way. I don’t know about an objective definition for what a GC is, one I quite like is “gives the illusion of infinite memory”, based on that it isn’t a GC. But there are also conservative GCs, RCs, etc, that fail different definitions also (leaving behind circular dependencies, having false positives, in reverse order), like in case of many things in CS, there isn’t an objective definition.
        Alifatisk 4y ago
        Thank you for the explanation, I think I get it now!
- tsimionescu 4y ago
  Theoretically someone could perhaps one day discover the theoretically optimal GC algorithm, and someone else could write the TeX of GCs using that algorithm, and then perhaps we'd have the final GC. Extremely unlikely that such an algorithm exists of course, and even if it did, looking at sorting will quickly suggests that improvements will keep being found even if the best asymptotic complexity had been achieved.
- mike_hearn 4y ago
  There are some dimensions yes, but I do wonder if GC research is starting to approach the point of being "solved" well enough that we'll see a drop in investment. Not yet, clearly, but approaching that territory. If you look at the very latest JVMs you have three GCs which a spread over throughput-optimized (parallel), a middle ground jack of all trades (g1), and latency-optimized (zgc). They're a lot more self configuring in the past, so no matter what needs your app has it's usually just one CLI switch to get something fairly optimal. But ZGC is going generational, at which point it will have significantly higher throughput than before. Also, all the JVM GCs can handle massive heaps these days (like, terabyte scale). So at that point the choice might become even simpler: just use ZGC all the time unless you can tolerate higher pauses and want to reclaim some CPU for the app, in which case go with parallel. And in many cases the right tradeoff between latency and performance could be inferred automatically from the frameworks and libraries that are on the classpath, meaning that for most apps even needing to make that choice could go away. If you have a GC that doesn't pause, can handle terabyte sized heaps, has great throughput, is largely or completely self-configuring, is portable, open source, supports dozens of languages and has clean code, there are really very few metrics left to optimize after that. It seems like HotSpot is nearly there, especially when combined with GraalVM for language support.
  - _a_a_a_ 4y ago
    > If you have a GC that doesn't pause, can handle terabyte sized heaps, has great throughput, is largely or completely self-configuring, is portable, open source, supports dozens of languages and has clean code Yeah. If.
    - mike_hearn 4y ago
      That's basically ZGC Generational + GraalVM. So, code that's available now albeit you'd have to compile it from version control (graalvm stable releases don't support zgc yet, released zgc isn't generational yet). Give it another year or so and that'll be shipping out of the box in ordinary JVMs.
      - 4y ago
- ignoramous 4y ago
  > Unless someone comes up with a no pause, no compute power no code fully correct GC? Functional programming languages can be: https://www.reddit.com/r/haskell/comments/d5d13i https://www.reddit.com/r/haskell/comments/d5d13i / https://archive.is/4iyaG https://archive.is/4iyaG
stingraycharles 4y ago
It’s just as “solved” as regular memory allocators are for C/C++ — it’s constantly evolving, with many competing solutions. TBB, tcmalloc, jemalloc, mimalloc, etc etc etc. Memory management is hard, and in a world where memory sizes keep increasing, new techniques being developed is expected and perfectly normal.
- kaba0 4y ago
  Hell, not even sorting algorithms are “solved”, even though they are more than half a century old.
  - TylerE 4y ago
    Tim sort, used in python, V8, Android, and Swift, was invented in this millennium.
    - re-thc 4y ago
      And there are yet newer and faster sorting algorithms being implemented.
      - vlovich123 4y ago
        Notably quadsort which if I’m remembering my etymology correctly has pdqsort, fluxsort, and glidesort as descendents
matsemann 4y ago
Lots of things in CS are actually cyclic: RAM is expensive, implement swapping from HDD. RAM gets cheaper, load all data there and instead optimize your code for CPU. Data gets bigger, need to go back to swapping again. Suddenly we get SSDs and hard drive access is lots faster, invent something new but similar to the old stuff. And so it goes, the bottleneck is always moved.
- JoachimS 4y ago
  And also in system design, computer architecture and engineering. T. H. Meyer and I. E. Sutherland coined this generational behaviour the "Wheel or Reincarnation" in their paper "On the Design of Display Processors." IMHO a paper that is still well worth reading: http://cva.stanford.edu/classes/cs99s/papers/myer-sutherland-design-of-display-processors.pdf http://cva.stanford.edu/classes/cs99s/papers/myer-sutherland...
_a_a_a_ 4y ago
Not an expert but bear in mind that there can't really be one single thing called a 'good' garbage collector, because the behaviour of the programs that produce the garbage can be hugely varied, and the garbage so produced can likewise be hugely varied, and how you want to recover it can depend on the platform you're running on (if embedded, you probably want reference counting the tight memory, in other circumstances you might be very happy just to leak everything and let the OS clean up at the end. Edit: yes, it's sometimes ok to leak). As somebody says elsewhere, it's multidimensional issue and a single dimensional garbage collector can't be a brilliant match for everything. The book "Garbage Collection" by Richard Jones, recently discussed on HN, is something I'd highly recommend you buy and read.
Ygg2 4y ago
Due to Rice theorem any interesting property of computer program can be solved by solving the halting problem.
- moonchild 4y ago
  That's backwards. One proof of rice's theorem relies on the fact that, if you could decide any interesting property of programs in general, then you could solve the halting problem; it doesn't follow that, if you could solve the halting problem, then you could decide any interesting property. It happens to be true that, if you could solve the halting problem, then you could decide any interesting property of programs; but this is simply because the antecedent is false.
  - Ygg2 4y ago
    > That's backwards. See Wikipedia entry for Rice theorem subsection proof by reduction from the halting problem. 1. Have intersting property solver (e.g. is input squared) 2. Convert solver to halting problem solver 3. Solver is undecidable So they are in some equatable/convertible.
    - moonchild 4y ago
      Being able to turn an interesting property solver into a halting problem solver is not the same thing as being able to turn a halting property solver into an interesting problem solver.
      - Ygg2 4y ago
        My claim or at least intent was you can solve interesting property solver like you can solve a halting problem. I.e. not in a satisfying way (no false negatives or false positives with unlimited iterations). You can solve it to some extent (e.g. does program terminate in X steps).
        UncleMeat 4y ago
executesorder66 4y ago
Java was released in 1995. I wonder if you have ever updated any software that came out before then? Surely you don't update your OS. Windows/Linux/Mac all came out before 1995, and must surely be "solved" by now. In fact you probably still use Windows 95. Surely Windows 98 or any later version can't be any better? What's crazy to me is the sort of cognitive dissonance that you must have to hold a view like that, and still apply software updates at all.
- deleted 4y ago
  [deleted]
darthrupert 4y ago
Java is still slower than C in its memory management for many cases, so we can safely say that this is not a solved problem.
- kryptiskt 4y ago
  Memory management for C is not itself a solved problem, not only is there a lot of performance to squeeze out of malloc itself (the benchmarks on https://github.com/microsoft/mimalloc https://github.com/microsoft/mimalloc exemplifies the variance between the implementations), but it's up to the programmer to implement memory management in the large in an efficient way, which is not an easy task. One sure mark of a slow C program is one with a ton of mallocs and frees strewn all over.
- kaba0 4y ago
  If we can know exactly where a particular object’s lifetime ends, then indeed we can write more efficient programs than possible with a GC, but that in the general case is not something we can determine at compile time (Rust’s lifetimes are a strict subset of the general case). Anything more dynamic will require some “ad hoc, informally-specified, bug-ridden, slow implementation of a GC”.
  - pron 4y ago
    Rust also relies on a GC for the more dynamic lifetimes in Rust programs (reference counting), it just doesn't call it a GC, and while Rust's GC has a lower footprint than tracing GCs, it has worse performance and it suffers from cycle problems. I wouldn't call it "bug ridden" (perhaps "limited" is a better term), but it is slow. Some think that reference counting gives better performance predictability than a tracing GC, but that is no longer true, certainly compared to the generational ZGC presented here. If you could determine the time where the collection would take place with a refcounting GC, i.e. when the last reference is cleared, you wouldn't need a refcounting GC. It is unpredictable pretty much by definition.
    - kaba0 4y ago
      That last line was just a play on this ( https://en.m.wikipedia.org/wiki/Greenspun%27s_tenth_rule https://en.m.wikipedia.org/wiki/Greenspun%27s_tenth_rule ), but you are right of course.
dwaite 4y ago
Optimal memory behavior and lifetime is highly application specific, so the behavior of an automatic system likewise will be better for some applications than others. In Java, the goal is to have something that performs reasonably well, without degenerative cases, for a wide variety of applications and services. It also has to handle cases where a monolithic code base results in a multitude of different memory behaviors. Even thinking too hard on the ideal behavior will negatively impact application code. The research field of garbage collectors is a study of trade-offs. A highly tuned, application-specific memory strategy will likely outperform Java, but the goal is to not require anyone to build such a thing for most software.
sideeffffect 4y ago
GC is by no way a solved thing. Let alone in Java! Consider these developments: * Distilling the Real Cost of Production Garbage Collectors https://twitter.com/stevemblackburn/status/1519641157621657600 https://twitter.com/stevemblackburn/status/15196411576216576... https://www.youtube.com/watch?v=OUZt0mo1xic https://www.youtube.com/watch?v=OUZt0mo1xic https://old.reddit.com/r/java/comments/udtdke/the_real_cost_of_production_garbage_collector/ https://old.reddit.com/r/java/comments/udtdke/the_real_cost_... https://old.reddit.com/r/ProgrammingLanguages/comments/udt2pf/distilling_the_real_cost_of_production_garbage/ https://old.reddit.com/r/ProgrammingLanguages/comments/udt2p... https://news.ycombinator.com/item?id=31192261 https://news.ycombinator.com/item?id=31192261 * Low-latency, high-throughput garbage collection https://twitter.com/stevemblackburn/status/1518386133746728960 https://twitter.com/stevemblackburn/status/15183861337467289... https://www.youtube.com/watch?v=1TLmawuxHfY https://www.youtube.com/watch?v=1TLmawuxHfY https://old.reddit.com/r/ProgrammingLanguages/comments/ubp2d8/lowlatency_highthroughput_garbage_collection/ https://old.reddit.com/r/ProgrammingLanguages/comments/ubp2d... https://old.reddit.com/r/java/comments/ubgyva/lxr_a_new_java_gc/ https://old.reddit.com/r/java/comments/ubgyva/lxr_a_new_java... https://news.ycombinator.com/item?id=31153434 https://news.ycombinator.com/item?id=31153434
datadeft 4y ago
Since garbage collection based memory models are mush more complex and require a lot of software engineering it is not a surprise that we have many iterations.
Jeff_Brown 4y ago
The name is a little misleading because once you know it's garbage, "collection" is trivial. The trick is to figure out what is garbage cheaply.
ackfoobar 4y ago
> You'd think it would be "solved" by now This can be an interesting inqury. Sad that you have to ruin it with snark. I guess in some sense it was "solved" more than a decade ago in Azul's C4 (Continuously Concurrent Compacting Collector). I wonder how a generational ZGC will compare against it.
- nielsbot 4y ago
  No snark intended actually
nayuki 4y ago
> You'd think it would be "solved" by now... Or is that just in Java world? I'm not sure what you mean but I'll try to relate. Automatic garbage collection is a problem not just in the Java world. It's also needed in JavaScript, Python, Go, Haskell, etc. Citation needed, but I suspect the Java Virtual Machine ecosystem has the most advanced GC algorithms in the world. Even if that's not true, I can tell you with certainty that other language environments have adopted features many years after Java did, such as JavaScript V8 introducing concurrent generational copying in year 2017 ( https://v8.dev/blog/orinoco-parallel-scavenger https://v8.dev/blog/orinoco-parallel-scavenger ). I'm sure there are examples in Go as well where their GC implemented features that Java had a decade earlier.
- kaba0 4y ago
  The JVM is definitely the state of the art when it comes to GC algorithms.
nielsbot 4y ago
People seem to think I was being snarky here, but I wasn't. It was honest surprise.

Crazy to me that garbage collection systems are a subject of continual evolution and discussion. You'd think it would be "solved" by now... Or is that just in Java world?

killingtime74 4y ago

I'm not sure what "solved" would mean for GC. Can't there always be improvements in maintainability, pause duration, correctness, throughput etc. Many dimensions to continually improve on. Unless someone comes up with a no pause, no compute power no code fully correct GC?

kanzenryu2 4y ago
Java already has that GC, it's called Epsilon https://blogs.oracle.com/javamagazine/post/epsilon-the-jdks-do-nothing-garbage-collector https://blogs.oracle.com/javamagazine/post/epsilon-the-jdks-...
- Alifatisk 4y ago
  Epsilon doesn't GC at all?
  - deleted 4y ago
    [deleted]
  - kaba0 4y ago
    I think it was a tongue in cheek reply, as it is indeed a no-code, no-pause, no-compute power GC that does eventually reclaim the garbage (at process exit).
    - Alifatisk 4y ago
      Correct me if I am wrong but does it really GC at all if you receive an OutOfMemoryError?
      - kaba0 4y ago
        It’s meant for short lived apps where you simply wouldn’t get OOM either way. I don’t know about an objective definition for what a GC is, one I quite like is “gives the illusion of infinite memory”, based on that it isn’t a GC. But there are also conservative GCs, RCs, etc, that fail different definitions also (leaving behind circular dependencies, having false positives, in reverse order), like in case of many things in CS, there isn’t an objective definition.
        Alifatisk 4y ago
        Thank you for the explanation, I think I get it now!
tsimionescu 4y ago
Theoretically someone could perhaps one day discover the theoretically optimal GC algorithm, and someone else could write the TeX of GCs using that algorithm, and then perhaps we'd have the final GC. Extremely unlikely that such an algorithm exists of course, and even if it did, looking at sorting will quickly suggests that improvements will keep being found even if the best asymptotic complexity had been achieved.
mike_hearn 4y ago
There are some dimensions yes, but I do wonder if GC research is starting to approach the point of being "solved" well enough that we'll see a drop in investment. Not yet, clearly, but approaching that territory. If you look at the very latest JVMs you have three GCs which a spread over throughput-optimized (parallel), a middle ground jack of all trades (g1), and latency-optimized (zgc). They're a lot more self configuring in the past, so no matter what needs your app has it's usually just one CLI switch to get something fairly optimal. But ZGC is going generational, at which point it will have significantly higher throughput than before. Also, all the JVM GCs can handle massive heaps these days (like, terabyte scale). So at that point the choice might become even simpler: just use ZGC all the time unless you can tolerate higher pauses and want to reclaim some CPU for the app, in which case go with parallel. And in many cases the right tradeoff between latency and performance could be inferred automatically from the frameworks and libraries that are on the classpath, meaning that for most apps even needing to make that choice could go away. If you have a GC that doesn't pause, can handle terabyte sized heaps, has great throughput, is largely or completely self-configuring, is portable, open source, supports dozens of languages and has clean code, there are really very few metrics left to optimize after that. It seems like HotSpot is nearly there, especially when combined with GraalVM for language support.
- _a_a_a_ 4y ago
  > If you have a GC that doesn't pause, can handle terabyte sized heaps, has great throughput, is largely or completely self-configuring, is portable, open source, supports dozens of languages and has clean code Yeah. If.
  - mike_hearn 4y ago
    That's basically ZGC Generational + GraalVM. So, code that's available now albeit you'd have to compile it from version control (graalvm stable releases don't support zgc yet, released zgc isn't generational yet). Give it another year or so and that'll be shipping out of the box in ordinary JVMs.
    - 4y ago
ignoramous 4y ago
> Unless someone comes up with a no pause, no compute power no code fully correct GC? Functional programming languages can be: https://www.reddit.com/r/haskell/comments/d5d13i https://www.reddit.com/r/haskell/comments/d5d13i / https://archive.is/4iyaG https://archive.is/4iyaG

stingraycharles 4y ago

It’s just as “solved” as regular memory allocators are for C/C++ — it’s constantly evolving, with many competing solutions. TBB, tcmalloc, jemalloc, mimalloc, etc etc etc. Memory management is hard, and in a world where memory sizes keep increasing, new techniques being developed is expected and perfectly normal.

kaba0 4y ago
Hell, not even sorting algorithms are “solved”, even though they are more than half a century old.
- TylerE 4y ago
  Tim sort, used in python, V8, Android, and Swift, was invented in this millennium.
  - re-thc 4y ago
    And there are yet newer and faster sorting algorithms being implemented.
    - vlovich123 4y ago
      Notably quadsort which if I’m remembering my etymology correctly has pdqsort, fluxsort, and glidesort as descendents

matsemann 4y ago

Lots of things in CS are actually cyclic: RAM is expensive, implement swapping from HDD. RAM gets cheaper, load all data there and instead optimize your code for CPU. Data gets bigger, need to go back to swapping again. Suddenly we get SSDs and hard drive access is lots faster, invent something new but similar to the old stuff. And so it goes, the bottleneck is always moved.

JoachimS 4y ago
And also in system design, computer architecture and engineering. T. H. Meyer and I. E. Sutherland coined this generational behaviour the "Wheel or Reincarnation" in their paper "On the Design of Display Processors." IMHO a paper that is still well worth reading: http://cva.stanford.edu/classes/cs99s/papers/myer-sutherland-design-of-display-processors.pdf http://cva.stanford.edu/classes/cs99s/papers/myer-sutherland...

_a_a_a_ 4y ago

Not an expert but bear in mind that there can't really be one single thing called a 'good' garbage collector, because the behaviour of the programs that produce the garbage can be hugely varied, and the garbage so produced can likewise be hugely varied, and how you want to recover it can depend on the platform you're running on (if embedded, you probably want reference counting the tight memory, in other circumstances you might be very happy just to leak everything and let the OS clean up at the end. Edit: yes, it's sometimes ok to leak). As somebody says elsewhere, it's multidimensional issue and a single dimensional garbage collector can't be a brilliant match for everything. The book "Garbage Collection" by Richard Jones, recently discussed on HN, is something I'd highly recommend you buy and read.

Ygg2 4y ago

Due to Rice theorem any interesting property of computer program can be solved by solving the halting problem.

moonchild 4y ago
That's backwards. One proof of rice's theorem relies on the fact that, if you could decide any interesting property of programs in general, then you could solve the halting problem; it doesn't follow that, if you could solve the halting problem, then you could decide any interesting property. It happens to be true that, if you could solve the halting problem, then you could decide any interesting property of programs; but this is simply because the antecedent is false.
- Ygg2 4y ago
  > That's backwards. See Wikipedia entry for Rice theorem subsection proof by reduction from the halting problem. 1. Have intersting property solver (e.g. is input squared) 2. Convert solver to halting problem solver 3. Solver is undecidable So they are in some equatable/convertible.
  - moonchild 4y ago
    Being able to turn an interesting property solver into a halting problem solver is not the same thing as being able to turn a halting property solver into an interesting problem solver.
    - Ygg2 4y ago
      My claim or at least intent was you can solve interesting property solver like you can solve a halting problem. I.e. not in a satisfying way (no false negatives or false positives with unlimited iterations). You can solve it to some extent (e.g. does program terminate in X steps).
      - UncleMeat 4y ago

executesorder66 4y ago

Java was released in 1995. I wonder if you have ever updated any software that came out before then? Surely you don't update your OS. Windows/Linux/Mac all came out before 1995, and must surely be "solved" by now. In fact you probably still use Windows 95. Surely Windows 98 or any later version can't be any better? What's crazy to me is the sort of cognitive dissonance that you must have to hold a view like that, and still apply software updates at all.

deleted 4y ago
[deleted]

darthrupert 4y ago

Java is still slower than C in its memory management for many cases, so we can safely say that this is not a solved problem.

kryptiskt 4y ago
Memory management for C is not itself a solved problem, not only is there a lot of performance to squeeze out of malloc itself (the benchmarks on https://github.com/microsoft/mimalloc https://github.com/microsoft/mimalloc exemplifies the variance between the implementations), but it's up to the programmer to implement memory management in the large in an efficient way, which is not an easy task. One sure mark of a slow C program is one with a ton of mallocs and frees strewn all over.
kaba0 4y ago
If we can know exactly where a particular object’s lifetime ends, then indeed we can write more efficient programs than possible with a GC, but that in the general case is not something we can determine at compile time (Rust’s lifetimes are a strict subset of the general case). Anything more dynamic will require some “ad hoc, informally-specified, bug-ridden, slow implementation of a GC”.
- pron 4y ago
  Rust also relies on a GC for the more dynamic lifetimes in Rust programs (reference counting), it just doesn't call it a GC, and while Rust's GC has a lower footprint than tracing GCs, it has worse performance and it suffers from cycle problems. I wouldn't call it "bug ridden" (perhaps "limited" is a better term), but it is slow. Some think that reference counting gives better performance predictability than a tracing GC, but that is no longer true, certainly compared to the generational ZGC presented here. If you could determine the time where the collection would take place with a refcounting GC, i.e. when the last reference is cleared, you wouldn't need a refcounting GC. It is unpredictable pretty much by definition.
  - kaba0 4y ago
    That last line was just a play on this ( https://en.m.wikipedia.org/wiki/Greenspun%27s_tenth_rule https://en.m.wikipedia.org/wiki/Greenspun%27s_tenth_rule ), but you are right of course.

dwaite 4y ago

Optimal memory behavior and lifetime is highly application specific, so the behavior of an automatic system likewise will be better for some applications than others. In Java, the goal is to have something that performs reasonably well, without degenerative cases, for a wide variety of applications and services. It also has to handle cases where a monolithic code base results in a multitude of different memory behaviors. Even thinking too hard on the ideal behavior will negatively impact application code. The research field of garbage collectors is a study of trade-offs. A highly tuned, application-specific memory strategy will likely outperform Java, but the goal is to not require anyone to build such a thing for most software.

sideeffffect 4y ago

GC is by no way a solved thing. Let alone in Java! Consider these developments: * Distilling the Real Cost of Production Garbage Collectors https://twitter.com/stevemblackburn/status/1519641157621657600 https://twitter.com/stevemblackburn/status/15196411576216576... https://www.youtube.com/watch?v=OUZt0mo1xic https://www.youtube.com/watch?v=OUZt0mo1xic https://old.reddit.com/r/java/comments/udtdke/the_real_cost_of_production_garbage_collector/ https://old.reddit.com/r/java/comments/udtdke/the_real_cost_... https://old.reddit.com/r/ProgrammingLanguages/comments/udt2pf/distilling_the_real_cost_of_production_garbage/ https://old.reddit.com/r/ProgrammingLanguages/comments/udt2p... https://news.ycombinator.com/item?id=31192261 https://news.ycombinator.com/item?id=31192261 * Low-latency, high-throughput garbage collection https://twitter.com/stevemblackburn/status/1518386133746728960 https://twitter.com/stevemblackburn/status/15183861337467289... https://www.youtube.com/watch?v=1TLmawuxHfY https://www.youtube.com/watch?v=1TLmawuxHfY https://old.reddit.com/r/ProgrammingLanguages/comments/ubp2d8/lowlatency_highthroughput_garbage_collection/ https://old.reddit.com/r/ProgrammingLanguages/comments/ubp2d... https://old.reddit.com/r/java/comments/ubgyva/lxr_a_new_java_gc/ https://old.reddit.com/r/java/comments/ubgyva/lxr_a_new_java... https://news.ycombinator.com/item?id=31153434 https://news.ycombinator.com/item?id=31153434

datadeft 4y ago

Since garbage collection based memory models are mush more complex and require a lot of software engineering it is not a surprise that we have many iterations.

Jeff_Brown 4y ago

The name is a little misleading because once you know it's garbage, "collection" is trivial. The trick is to figure out what is garbage cheaply.

ackfoobar 4y ago

> You'd think it would be "solved" by now This can be an interesting inqury. Sad that you have to ruin it with snark. I guess in some sense it was "solved" more than a decade ago in Azul's C4 (Continuously Concurrent Compacting Collector). I wonder how a generational ZGC will compare against it.

nielsbot 4y ago
No snark intended actually

nayuki 4y ago

> You'd think it would be "solved" by now... Or is that just in Java world? I'm not sure what you mean but I'll try to relate. Automatic garbage collection is a problem not just in the Java world. It's also needed in JavaScript, Python, Go, Haskell, etc. Citation needed, but I suspect the Java Virtual Machine ecosystem has the most advanced GC algorithms in the world. Even if that's not true, I can tell you with certainty that other language environments have adopted features many years after Java did, such as JavaScript V8 introducing concurrent generational copying in year 2017 ( https://v8.dev/blog/orinoco-parallel-scavenger https://v8.dev/blog/orinoco-parallel-scavenger ). I'm sure there are examples in Go as well where their GC implemented features that Java had a decade earlier.

kaba0 4y ago
The JVM is definitely the state of the art when it comes to GC algorithms.

nielsbot 4y ago

People seem to think I was being snarky here, but I wasn't. It was honest surprise.