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

81–90 of 126 posts

Re: Z Garbage Collector: The Next Generation

#81

Post by Ygg2 »

UncleMeat wrote: post #72
Ygg2 wrote: post #61

Earlier quoted context omitted.

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

But this is vacuous and unrelated to the halting problem or Rice's Thm. A program that emits "Yes" on every input will decide some property of programs with zero false negatives.

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

Re: Z Garbage Collector: The Next Generation

#82

Post by kaba0 »

addaon wrote: post #68
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…

Are there any production-ready GCs that have strictly bounded latency? I'm not aware of any, and that means that GC is still too immature for use in about 95% of the computers in my house, the deeply embedded ones.

Strictly bounded anything (hard real-time) is an entirely different category, with very few uses for the average person - and contrary to what one might think from its name, it is not “fast” at all. It’s mostly about “calculating the trajectory of that incoming projectile should definitely happen in 0.3s”, which is many orders of magnitude more than what a modern computer would take to do 3 multiplications.

But to answer your question, there is JamaicaVM and many niche JVM implementations with hard real time GCs — but it’s simply false that a GC would be somehow a problem for most of your devices.

Re: Z Garbage Collector: The Next Generation

#83

Post by UncleMeat »

Ygg2 wrote: post #81
UncleMeat wrote: post #72

Earlier quoted context omitted.

But this is vacuous and unrelated to the halting problem or Rice's Thm. A program that emits "Yes" on every input will decide some property of programs with zero false negatives.

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.

Re: Z Garbage Collector: The Next Generation

#84

Post by _a_a_a_ »

pron wrote: post #60
_a_a_a_ wrote: post #52

Earlier quoted context omitted.

No pauses and high throughput? Do you have any links to how it does this? I'd really like to know.

That's the subject of the video being discussed. More technical info here and in the links: https://openjdk.org/jeps/439

Appreciated.

Re: Z Garbage Collector: The Next Generation

#85

Post by viraptor »

trollied wrote: post #64
viraptor wrote: post #54

Earlier quoted context omitted.

JVM still has some limitations. https://stackoverflow.com/a/2682962/31667 Those actually influence either the design or the performance of the higher level language.

That post is 13 years old.

Yes it is - that doesn't make it wrong. The type erasure is still a JVM limitation.

Re: Z Garbage Collector: The Next Generation

#86

Post by millerm »

pohl wrote: post #71
millerm wrote: post #53

Earlier quoted context omitted.

I say this all the time to people that say they want to use Node because they hate Java. There are so many languages that you can execute on the JVM. It’s almost unfortunate that it’s still called the JVM. It think the JVM needs a re-branding. Even if they just change the meaning of the J. I suppose that is what GraalVM is doing, but it’s an awful name and its purpose isn’t being conveyed well. The JDK should just sw…

I haven't been in that world since Java 7. What's the startup time on the JVM these days? It used to be a pretty hefty cost, and it didn't seem like it would get much better because of the way class loading was done.

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

Re: Z Garbage Collector: The Next Generation

#87

Post by addaon »

kaba0 wrote: post #82
addaon wrote: post #68

Earlier quoted context omitted.

Are there any production-ready GCs that have strictly bounded latency? I'm not aware of any, and that means that GC is still too immature for use in about 95% of the computers in my house, the deeply embedded ones.

Strictly bounded anything (hard real-time) is an entirely different category, with very few uses for the average person - and contrary to what one might think from its name, it is not “fast” at all. It’s mostly about “calculating the trajectory of that incoming projectile should definitely happen in 0.3s”, which is many orders of magnitude more than what a modern computer would take to do 3 multiplications. But to an…

Hard real-time has a huge amount of uses for the average person. I just made toast -- the software-controlled thermostat in my toaster oven has (slow) hard bounds on its sense-to-control latency to avoid dangerous overheating. Before that, I brushed my teeth -- the brushed motor controller detects a motor stall by increased current if I brush too hard and stall it, shuts down the motor to avoid overheating (with a hard real-time sense-to-actuate constraint), and beeps to inform me. Then I spent some time on HN, with a laptop with PMICs and other microcontrollers that have hard real-time constraints all over the place. By far the majority of my computer interactions so far today have been with computers that have hard real-time constraints, and I haven't even gotten in my car yet!

Re: Z Garbage Collector: The Next Generation

#89

Post by pohl »

millerm wrote: post #86
pohl wrote: post #71

Earlier quoted context omitted.

I haven't been in that world since Java 7. What's the startup time on the JVM these days? It used to be a pretty hefty cost, and it didn't seem like it would get much better because of the way class loading was done.

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?

Re: Z Garbage Collector: The Next Generation

#90

Post by pkolaczk »

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's lifetimes is a strict subset of the general case, but it covers a good majority of use-cases with affine types - which means trivial allocation and deallocation. The number of times I had to use lifetime specifiers or dynamic lifetimes (RefCell/Rc/Arc) is extremely low, so low that it is not even a blip on the profile. Also, unlike most GC languages, Rust favors stack allocation over heap allocation, which makes most Rust program allocation rates several orders of magnitude lower than any Java program I saw (at the expense of more inter-stack copying, but that is extremely cheap because the top of the stack is almost always in L1 cache).
Post reply on HN