Live data from Hacker News

Z Garbage Collector: The Next Generation

inside.java

121–126 of 126 posts

Re: Z Garbage Collector: The Next Generation

#121
post #112

Earlier quoted context omitted.

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

Yes. And you said

> A program that emits "Yes" on every input will decide some property of programs with zero false negatives.

Followed by

> any semantic property that is not either always true or always false for all program executions

So what you said is your decider always outputs true. That's not an interesting property, because it's true for all inputs.

Btw what is the point of your argument? It still doesn't refute my initial statement. If you want to determine an interesting property of program like leaks, or automatic lifetime calculation or whether output is square of input, you run into Rice Theorem, which makes the problem undecidable. In other words it's impossible to get correct yes and no algorithmically.

Re: Z Garbage Collector: The Next Generation

#122
post #120
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 cert…

The JVM is definitely the state of the art when it comes to GC algorithms.

Re: Z Garbage Collector: The Next Generation

#123
post #117
post #56

Earlier quoted context omitted.

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.

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

I don't think so. You don't know when memory will be freed or how long that would take only that it will be freed as soon as possible. The end result is lower footprint but that's about it.

Re: Z Garbage Collector: The Next Generation

#124
post #89
post #86

Earlier quoted context omitted.

Not sure what startup time matters for running a persistent service is, and it's obviously tied to hardware. You can get applications up and running in less than second or so (we were using Micronaut to resolve dependencies at compile time). If you use GraalVM you can compile to native code and now we're talking a few tens of milliseconds to get an application up and running (or execute and exit).

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?

Not sure if it's a "bias". The JVM does start up slowly. This has never been an issue for me in all the years I've been using Clojure.

If I need "scripts" with short start-up times, I'll use Babashka (GraalVM) or ClojureScript (Node). Same language, instant start-up. But then I don't expect to get good performance from those VMs for long-running services with large memory allocations.

Use the right tool for the job at hand?

Re: Z Garbage Collector: The Next Generation

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

No snark intended actually

Re: Z Garbage Collector: The Next Generation

#126
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?

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