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

111–120 of 126 posts

Re: Z Garbage Collector: The Next Generation

#111

Post by aseipp »

tkot wrote: post #110
pwagland wrote: post #67

Earlier quoted context omitted.

Yes, on small heaps you are still forced to use a 64bit pointer instead of a 32bit pointer, which means that your per-object overhead is higher, this means that on "normal" heap sizes, That said, for a lot of use cases, this is still a reasonable trade-off to make, but it probably won't be promoted to "standard" until it's better in all use cases.

Wouldn't UseCompressedOops flag alleviate the issue for smaller heaps?

ZGC relies on the space of 64-bit pointer (and the size of the 64-bit virtual address space) for its pointer coloring algorithm, and so it is by definition incompatible with UseCompressedOops even at small sizes.

I suppose it's possible to fix this with a change to the design in some way. But if you have a heap smaller than 32GB, the existing G1 would probably work well too. ZGC shines much more on very large heap sizes since that's where long tail GC latency often hits hardest.

Re: Z Garbage Collector: The Next Generation

#112

Post by Ygg2 »

UncleMeat wrote: post #83
Ygg2 wrote: post #81

Earlier quoted context omitted.

Hence, the interesting property part. Program that returns "true" on everything is trivial.

"Interesting property", as defined by Rice's Thm, is "any semantic property that is not either always true or always false for all program executions." It does not mean "interesting" as in "interesting to humans." And I'm talking about the decider, not the program being fed as input.

I'm not a computer scientist, but I am aware Interesting doesn't mean interesting to humans.

> And I'm talking about the decider

EDIT: If by decider you mean program tested for having property P, that's a particular case and not applicable in general, ergo non-important (a program that's a NOP can be shown to leak no memory as well).

So the property P you are testing always returns true? Then it's not interesting per your definition. Leaking memory however is interesting.

Re: Z Garbage Collector: The Next Generation

#113

Post by pohl »

kaba0 wrote: post #108
pohl wrote: post #89

Earlier quoted context omitted.

That was always the story back then, too — the assumption that no one writes anything other than services with long uptimes. No CLI tools, no lambdas, no quick-launching GUIs. Sounds like that bias hasn't really changed over the years?

You pay for what you use. If you bring in a litany of libraries to connect to some endpoint in every conceivable IPC mechanism then sure, it will take some time (but let’s not forget that it would also take considerable time with native machine code). But besides very very frequently run CLI tools like ls, the problem is entirely overblown. Come on, quick-launching GUIs? I hardly even remember that being a thing.

You pay for what you use.

Exciting, if true. So, for example, could I choose to not use garbage collection or class loading or JIT compilation and avoid paying their costs?

Re: Z Garbage Collector: The Next Generation

#114

Post by [deleted] »

pron wrote: post #56
yw3410 wrote: post #50

Earlier quoted context omitted.

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.

It does not. Maintaining the counter requires more work than tracing GCs do, and you don't know in advance when the last reference is dropped. True, you get more promptness in deallocation (not the same as predictability), which reduces the footprint but comes at the expense of compaction, the lack of which in most refcounting GCs also adds unpredictability. In contrast, in the common case, allocation with a compacti…

[deleted]

Re: Z Garbage Collector: The Next Generation

#115

Post by ackfoobar »

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?

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

Re: Z Garbage Collector: The Next Generation

#116

Post by kaba0 »

pohl wrote: post #113
kaba0 wrote: post #108

Earlier quoted context omitted.

You pay for what you use. If you bring in a litany of libraries to connect to some endpoint in every conceivable IPC mechanism then sure, it will take some time (but let’s not forget that it would also take considerable time with native machine code). But besides very very frequently run CLI tools like ls, the problem is entirely overblown. Come on, quick-launching GUIs? I hardly even remember that being a thing.

You pay for what you use. Exciting, if true. So, for example, could I choose to not use garbage collection or class loading or JIT compilation and avoid paying their costs?

I was quite obviously talking about loading many classes.

But.. yeah, you can disable the GC and also the JIT compiler, for whatever reason.

Re: Z Garbage Collector: The Next Generation

#117

Post by yw3410 »

pron wrote: post #56
yw3410 wrote: post #50

Earlier quoted context omitted.

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.

It does not. Maintaining the counter requires more work than tracing GCs do, and you don't know in advance when the last reference is dropped. True, you get more promptness in deallocation (not the same as predictability), which reduces the footprint but comes at the expense of compaction, the lack of which in most refcounting GCs also adds unpredictability. In contrast, in the common case, allocation with a compacti…

But what you call promptness is predictability from the PoV of the programmer, no?

I don't think I've mentioned performance anywhere; thanks for the paper I'll take a look.

Re: Z Garbage Collector: The Next Generation

#118

Post by UncleMeat »

Ygg2 wrote: post #112
UncleMeat wrote: post #83

Earlier quoted context omitted.

"Interesting property", as defined by Rice's Thm, is "any semantic property that is not either always true or always false for all program executions." It does not mean "interesting" as in "interesting to humans." And I'm talking about the decider, not the program being fed as input.

I'm not a computer scientist, but I am aware Interesting doesn't mean interesting to humans. > And I'm talking about the decider EDIT: If by decider you mean program tested for having property P, that's a particular case and not applicable in general, ergo non-important (a program that's a NOP can be shown to leak no memory as well). So the property P you are testing always returns true? Then it's not interesting per…

No that's not what I mean by decider. The decider is the program that takes the other program as input and tells you whether that input program has the semantic property you want.

The only noninteresting semantic properties of programs that exist are "this is a program" and "this is not a program."

Re: Z Garbage Collector: The Next Generation

#119

Post by nayuki »

vips7L wrote: post #88

Love ZGC's autotuning, I'm hoping for the day where we don't need -Xmx as well!

It seems ZGC's autotuning is following in the footsteps of Azul's proprietary C4 (Continuously Concurrent Compacting Collector) which came a decade or two earlier. Both GCs are low-latency and their main tuning option is just the heap size.

Re: Z Garbage Collector: The Next Generation

#120

Post by nayuki »

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?

> 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 ). I'm sure there are examples in Go as well where their GC implemented features that Java had a decade earlier.

Post reply on HN