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

JDK 27 G1/Parallel/Serial GC Changes

tschatzl.github.io

Post reply on HN
Print view View original

21–30 of 36 posts

Re: JDK 27 G1/Parallel/Serial GC Changes

#21

Post by hedora »

pron wrote: post #18
hedora wrote: post #17

Earlier quoted context omitted.

Concretely, what are current tail latencies, worst case? Ten years ago, “rewrite in C++” was definitely easier than getting the Java GC to stay up under server load. Most servers I work with run on big machines and are the only process, so figure a 100-250GB heap that lives for months, all async, small requests, so insane amounts of Future and String allocation spam. Optimizing that stuff away in Java is harder than…

> Concretely, what are current tail latencies, worst case? Well under 1ms for ZGC (to the point that OS-caused hiccups are of similar magnitudes). > Ten years ago, “rewrite in C++” was definitely easier than getting the Java GC to stay up under server load. Both could have been hard in some cases, but open-source "pauseless" GCs are only 3 years old (and all of the JDK's GCs are nothing like what they were ten years…

In rust, I usually just make sure stuff is not Box, and try to reuse buffers. That generally gets the memory allocator completely out of the way (except for async).

The remaining allocator performance problems are mostly due to it zeroing allocated memory unless I use unsafe. Is java able to stackify most new Object calls and elide default initialization of object members these days?

I’m surprised to hear there is no demand for compiler enforced/facilitated thread safety in Java. That was a major pain point in all the Java code bases I’ve worked with in the past, and is a headline safety feature for rust (which goes even further and enforces aliasing rules) and JS. Could you be seeing selection bias in your user base?

Re: JDK 27 G1/Parallel/Serial GC Changes

#22

Post by hedora »

stmw wrote: post #20
hedora wrote: post #17

Earlier quoted context omitted.

Concretely, what are current tail latencies, worst case? Ten years ago, “rewrite in C++” was definitely easier than getting the Java GC to stay up under server load. Most servers I work with run on big machines and are the only process, so figure a 100-250GB heap that lives for months, all async, small requests, so insane amounts of Future and String allocation spam. Optimizing that stuff away in Java is harder than…

As the OC, I think my view is somewhere in the middle - I am neither as optimistic about it being "great now" nor do I think that "rewrite in C++" 10 years ago was easier. My reason for disagreeing with the former view is that improvements in physical RAM available and tendency towards smaller workloads have allowed many Java (or other GC runtimes) to essentially "fix their problems because hardware got better". So y…

It definitely was easier for the projects I worked on, but they are exactly the use case where the heap is long lived and most of the machine.

I’ve also worked on systems with lots of small processes, and the operational issues that creates dwarfs GC problems: It takes one middle tier machine, and adds 64-128 network boundaries, and also creates an extremely difficult static memory allocation problem.

I know people do it anyway, but it’s rare that they can articulate a decent technical reason for it, and it wastes something like 90% of the hardware (even in carefully optimized code bases / deployments).

Anyway, I’m not the target market for such stuff.

Re: JDK 27 G1/Parallel/Serial GC Changes

#23

Post by mdavidn »

hedora wrote: post #16
pron wrote: post #13

Earlier quoted context omitted.

Use ZGC.

Does it provide hard latency bounds like Azul does (did?), and are they lower than disk/network latencies on modern hardware? I moved to c++/rust years ago because those languages do, and tens of milliseconds matter for network services. At the time Java could pause for 10’s of seconds, which was 1000x worse than waiting for a spinning disk to seek. These days, disks are 100s micros to single digit millis, so I guess…

> If you hammer a 100GB-1TB heap in steady state with small allocations for, say, a month at 100% CPU, does it eventually do the typical Java thing, where a major compaction takes the process down for seconds or even minutes, or does it just slow down application requests so it can keep up with load?

No. Every garbage collection in Java relocates objects. Compared to malloc, memory fragmentation in long-lived processes is less of a concern. Freelists track only large segments of available memory. The allocator reserves a segment per thread and simply advances a pointer. Small short-lived objects are never visited by the collector. Instead, live siblings are relocated elsewhere before the entire segment is reclaimed.

The above holds true for all of the collectors. The difference is how they deal with concurrent changes to object pointers by the application. Generally, stopping the world uses less net CPU than the memory barriers required by G1GC and ZGC, but most applications are willing to provide more memory and CPU in exchange for shorter pauses.

Re: JDK 27 G1/Parallel/Serial GC Changes

#24

Post by Traubenfuchs »

If any JDK wizard is present:

In my opinion, the thing the JRE is REALLY missing is a single process level memory limit setting.

Nowadays you still have to consider the off heap memory when limiting a JRE processes max memory.

To clarify: -XX:MaxRAMPercentage should not exist. Instead the process should be told: „You can use x mb/gb of memory. Use of that what you need for offheap and use the rest for heap.“

That setting is embarassing. Figuring out its value is a mixture of voodoo, vibe-driven guessing and playing the game of „how much wasted memory do you want to risk to prevent a crash?“.

Give us -XX:MaxProcessMemory=4g please. Why doesn‘t this exist?

Re: JDK 27 G1/Parallel/Serial GC Changes

#25

Post by pron »

hedora wrote: post #21
pron wrote: post #18

Earlier quoted context omitted.

> Concretely, what are current tail latencies, worst case? Well under 1ms for ZGC (to the point that OS-caused hiccups are of similar magnitudes). > Ten years ago, “rewrite in C++” was definitely easier than getting the Java GC to stay up under server load. Both could have been hard in some cases, but open-source "pauseless" GCs are only 3 years old (and all of the JDK's GCs are nothing like what they were ten years…

In rust, I usually just make sure stuff is not Box , and try to reuse buffers. That generally gets the memory allocator completely out of the way (except for async). The remaining allocator performance problems are mostly due to it zeroing allocated memory unless I use unsafe. Is java able to stackify most new Object calls and elide default initialization of object members these days? I’m surprised to hear there is n…

> In rust, I usually just make sure stuff is not Box, and try to reuse buffers. That generally gets the memory allocator completely out of the way (except for async).

You say "just", but this is easy when programs are small. The problem is that this gets harder and harder and harder as programs grow large (the whole point of the JVM's design was to address the performance issues that plague large C++ programs). E.g. someone who works at one of the world's largest tech companies just told me that they have problems with Rust programs spending 30% of their CPU on memory management even when they're as small as a couple hundreds of thousands of LOC.

> Is java able to stackify most new Object calls and elide default initialization of object members these days?

No, the general idea is to just make memory management efficient (although some objects are "stackified" and the compiler will elide zeroing when non-defaults are passed to a constructor). Now, I say "just", but this used to come at the cost of GC pauses and larger footprint. Now it only comes at the cost of a larger footprint.

But there is a definite choice here when it comes to performance. Low level languages give you control that means performance is attained through manual effort. Java takes away control to improve effort-per-performance. Roughly speaking, these tradeoffs mean that when programs are small and the extra effort is manageable, low-level languages are hard to beat, but when programs are large, it is Java that is hard to beat.

> I’m surprised to hear there is no demand for compiler enforced/facilitated thread safety in Java. That was a major pain point in all the Java code bases I’ve worked with in the past, and is a headline safety feature for rust (which goes even further and enforces aliasing rules) and JS.

This used to be a bigger problem when locks were the main mechanism for sharing data among threads. Now, with the wide selection of concurrent data structures, such problems don't occur as much. I'm not saying they don't occur at all, just not frequently enough to become a major priority.

Also, safe Rust's data-race freedom comes at the cost of requiring unsafe for benign races, which are not uncommon in concurrent algorithms (i.e. it excludes even "good" races). This may be fine in languages whose view on performance is "with enough effort you can get good performance", but, as I said, Java is about making more "naive" programs fast with little effort.

Re: JDK 27 G1/Parallel/Serial GC Changes

#26

Post by noelwelsh »

hedora wrote: post #21
pron wrote: post #18

Earlier quoted context omitted.

> Concretely, what are current tail latencies, worst case? Well under 1ms for ZGC (to the point that OS-caused hiccups are of similar magnitudes). > Ten years ago, “rewrite in C++” was definitely easier than getting the Java GC to stay up under server load. Both could have been hard in some cases, but open-source "pauseless" GCs are only 3 years old (and all of the JDK's GCs are nothing like what they were ten years…

In rust, I usually just make sure stuff is not Box , and try to reuse buffers. That generally gets the memory allocator completely out of the way (except for async). The remaining allocator performance problems are mostly due to it zeroing allocated memory unless I use unsafe. Is java able to stackify most new Object calls and elide default initialization of object members these days? I’m surprised to hear there is n…

> Is java able to stackify most new Object calls and elide default initialization of object members these days?

Escape analysis in OpenJDK will stack allocate values where it can show it is safe to do so. Project Valhalla is also reducing the memory footprint of objects.

As for thread safety, that is more of a language concern than a runtime one. Amongst JVM languages Scala is leading here AFAIK. Its "capture checking"[1] provides thread safety (e.g. [2]) and actually covers escape analysis as well. On Scala Native (the native code backend for Scala) capture checking can be used for safe stack allocation and safe arena allocation.

[1]: https://docs.scala-lang.org/scala3/reference/experimental/cc... [2]: https://softwaremill.com/understanding-capture-checking-in-s...

Re: JDK 27 G1/Parallel/Serial GC Changes

#27

Post by pron »

stmw wrote: post #20
hedora wrote: post #17

Earlier quoted context omitted.

Concretely, what are current tail latencies, worst case? Ten years ago, “rewrite in C++” was definitely easier than getting the Java GC to stay up under server load. Most servers I work with run on big machines and are the only process, so figure a 100-250GB heap that lives for months, all async, small requests, so insane amounts of Future and String allocation spam. Optimizing that stuff away in Java is harder than…

As the OC, I think my view is somewhere in the middle - I am neither as optimistic about it being "great now" nor do I think that "rewrite in C++" 10 years ago was easier. My reason for disagreeing with the former view is that improvements in physical RAM available and tendency towards smaller workloads have allowed many Java (or other GC runtimes) to essentially "fix their problems because hardware got better". So y…

> So you can waste more RAM, waste more cycles

Just to be clear, the main reason for the use of moving collectors in the first place is to waste less cycles on memory management (otherwise we wouldn't use them). They exist to serve as an optimisation.

> We have been 3 years away from GC solving memory management for at least 30 years.

It's now 3 years in the past (since Generational ZGC); e.g. see https://netflixtechblog.com/bending-pause-times-to-your-will.... Of course, it doesn't solve all imaginable memory management issues, but in practice it makes it a non-issue for a large class of interesting and very common programs.

Re: JDK 27 G1/Parallel/Serial GC Changes

#28

Post by stmw »

pron wrote: post #27
stmw wrote: post #20

Earlier quoted context omitted.

As the OC, I think my view is somewhere in the middle - I am neither as optimistic about it being "great now" nor do I think that "rewrite in C++" 10 years ago was easier. My reason for disagreeing with the former view is that improvements in physical RAM available and tendency towards smaller workloads have allowed many Java (or other GC runtimes) to essentially "fix their problems because hardware got better". So y…

> So you can waste more RAM, waste more cycles Just to be clear, the main reason for the use of moving collectors in the first place is to waste less cycles on memory management (otherwise we wouldn't use them). They exist to serve as an optimisation. > We have been 3 years away from GC solving memory management for at least 30 years. It's now 3 years in the past (since Generational ZGC); e.g. see https://netflixtech…

Maybe I should've mentioned at the start that I've implemented several GCs and worked on several Java VM implementations, so I am generally familiar with the tradeoffs between GC algorithms and other runtime details.

Even in the very positive blog you linked, you see statements like * "ZGC has a fixed overhead 3% of the heap size, requiring more native memory than G1. .." and * "Reference processing is also only performed in major collections with ZGC. We paid particular attention to deallocation of direct byte buffers, but we haven’t seen any impact thus far. This difference in reference processing did cause a performance problem with JSON thread dump support, but that’s a unusual situation caused by a framework accidentally creating an unused ExecutorService instance for every request."

This was my point about how this sort of thing is a type of manual memory management.

As for waste more RAM, waste more cycles wasn't a statemnt about whether a particular GC is better-performing for certain situations, but that the overall improvement likely has more to do with improvements in CPU speeds and RAM size, than the latest GC version (which tends to simply make a different set of engineering tradeoffs).

Re: JDK 27 G1/Parallel/Serial GC Changes

#29

Post by stmw »

pron wrote: post #25
hedora wrote: post #21

Earlier quoted context omitted.

In rust, I usually just make sure stuff is not Box , and try to reuse buffers. That generally gets the memory allocator completely out of the way (except for async). The remaining allocator performance problems are mostly due to it zeroing allocated memory unless I use unsafe. Is java able to stackify most new Object calls and elide default initialization of object members these days? I’m surprised to hear there is n…

> In rust, I usually just make sure stuff is not Box , and try to reuse buffers. That generally gets the memory allocator completely out of the way (except for async). You say "just", but this is easy when programs are small. The problem is that this gets harder and harder and harder as programs grow large (the whole point of the JVM's design was to address the performance issues that plague large C++ programs). E.g.…

It is fair that there are many ways to be slow in any number of programming languages. I'm surprised to hear "Rust programs spending 30% of their CPU on memory management even when they're as small as a couple hundreds of thousands of LOC", although I can visualize some unique workloads where that's unavoidable irrespective of language & runtime.
Post reply on HN