logoalt Hacker News

prontoday at 2:09 PM2 repliesview on HN

There are two practical lessons here:

1. Upgrade your JDK for the best performance (as the article says, the slowdown is gone in JDK 26).

2. Don't try to help the GC by pooling objects. Mutating old objects can be expensive, while allocating new ones is cheap (at least for objects that don't do some exceptionally expensive initialisation).


Replies

marginalia_nutoday at 3:04 PM

Object pooling still has its place, but like any optimization it needs to be based on benchmarks and shouldn't be done haphazardly. Blindly pooling objects will lead to regressions and resource contention more often than improvements.

There are also middle ground options, like pooling objects but giving the pool a lifecycle that is tied to a request.

cogman10today at 3:12 PM

Honestly, I don't really understand why G1 is being pushed so hard.

The parallel collector is a perfectly fine collector, particularly for smaller heaps. Even the serial collector isn't bad for things like a containerized environment, yet G1 replaces it by default now [1].

It's not a bad algorithm, but especially when you start talking about sub 2G environments I've not seen a situation where the parallel and serial collectors won't handily beat G1 on pretty much every metric. Major collectors with modern CPUs just doesn't take much time for a lot of memory.

[1] https://openjdk.org/jeps/523