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

31–40 of 126 posts

Re: Z Garbage Collector: The Next Generation

#31

Post by TylerE »

kaba0 wrote: post #26
stingraycharles wrote: post #4

Earlier quoted context omitted.

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.

Hell, not even sorting algorithms are “solved”, even though they are more than half a century old.

Tim sort, used in python, V8, Android, and Swift, was invented in this millennium.

Re: Z Garbage Collector: The Next Generation

#32

Post by _a_a_a_ »

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…

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

Re: Z Garbage Collector: The Next Generation

#34

Post by ignoramous »

killingtime74 wrote: post #3
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?

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?

> 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://archive.is/4iyaG

Re: Z Garbage Collector: The Next Generation

#35

Post by pron »

kaba0 wrote: post #28
darthrupert wrote: post #22

Earlier quoted context omitted.

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.

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

Re: Z Garbage Collector: The Next Generation

#36

Post by re-thc »

pron wrote: post #23
WantonQuantum wrote: post #18

Note that the Z Garbage Collector was released in JVM 11 so it’s about 5 years old now.

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

Re: Z Garbage Collector: The Next Generation

#37

Post by re-thc »

TylerE wrote: post #31
kaba0 wrote: post #26

Earlier quoted context omitted.

Hell, not even sorting algorithms are “solved”, even though they are more than half a century old.

Tim sort, used in python, V8, Android, and Swift, was invented in this millennium.

And there are yet newer and faster sorting algorithms being implemented.

Re: Z Garbage Collector: The Next Generation

#39

Post by Ygg2 »

moonchild wrote: post #19
Ygg2 wrote: post #13

Earlier quoted context omitted.

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

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.

Re: Z Garbage Collector: The Next Generation

#40

Post by kaba0 »

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…

That last line was just a play on this ( https://en.m.wikipedia.org/wiki/Greenspun%27s_tenth_rule ), but you are right of course.
Post reply on HN