Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Z Garbage Collector: The Next Generation

inside.java

Post reply on HN
Print view View original

41–50 of 126 posts

Re: Z Garbage Collector: The Next Generation

#41

Post by Someone »

mike_hearn wrote: post #20
killingtime74 wrote: post #3

Earlier quoted context omitted.

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?

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 confi…

The hardware still evolves, so at the least, garbage collectors will have to be tuned or self-tune themselves for that.

I also think it’s unlikely that a GC can be written that handles both terabyte sized heaps on machines with hundreds of cores and megabyte sized heaps on single-CPU systems well.

Re: Z Garbage Collector: The Next Generation

#42

Post by JoachimS »

matsemann wrote: post #8
nielsbot wrote: post #2

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?

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.

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...

Re: Z Garbage Collector: The Next Generation

#44

Post by krylon »

re-thc wrote: post #36
pron wrote: post #23

Earlier quoted context omitted.

Yes, but generational ZGC ( https://openjdk.org/jeps/439 ) has not been released yet. Possibly in JDK 21 this September.

Might have been easier calling it ZGC 2.0

If it's generational, ZGC Junior would be more appropriate. ZGC II, maybe.

(SCNR)

Re: Z Garbage Collector: The Next Generation

#45

Post by moonchild »

Ygg2 wrote: post #39
moonchild wrote: post #19

Earlier quoted context omitted.

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…

> 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.

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.

Re: Z Garbage Collector: The Next Generation

#46

Post by mike_hearn »

_a_a_a_ wrote: post #32
mike_hearn wrote: post #20

Earlier quoted context omitted.

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 confi…

> 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.

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.

Re: Z Garbage Collector: The Next Generation

#48

Post by mike_hearn »

Someone wrote: post #41
mike_hearn wrote: post #20

Earlier quoted context omitted.

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 confi…

The hardware still evolves, so at the least, garbage collectors will have to be tuned or self-tune themselves for that. I also think it’s unlikely that a GC can be written that handles both terabyte sized heaps on machines with hundreds of cores and megabyte sized heaps on single-CPU systems well.

Single GC, no. Single VM, yes. HotSpot serial GC is designed for the latter use case. I forgot to mention it before but it's still there and supported, I think even selected automatically in some cases.

But there aren't so many single core systems with megabyte sized heaps anymore. Even watches are multi-core these days.

Re: Z Garbage Collector: The Next Generation

#50

Post by yw3410 »

pron wrote: post #35
kaba0 wrote: post #28

Earlier quoted context omitted.

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”.

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 tracin…

It does give better performance predictability! Decrementing a refcount may either be a no-op or expensive but crucially the op can happen only during that particular call, nowhere else.
Post reply on HN