Why is Arrays.fill 265 times slower on G1GC?

hyperpape•about 2 hours ago

I'm genuinely curious about the effect, but I simply don't have patience for the AI writing. Can anyone give an actual non-garbage explanation with some respect for the reader?

Slightly less annoying summary from ChatGPT free: https://chatgpt.com/share/6a9ac7a3-15a0-83eb-8c2a-6f72cd9beb....

Caveat emptor: it makes high level sense, but I haven’t thought about it in detail.

marcianx•about 2 hours ago

I'm genuinely curious: I read through the article and the narrative felt deliberate and didn't trigger my AI-radar. What made you think it was AI written?

zbentley•30 minutes ago

It’s rife with “and that’s the important thing. $thing”-type constructions. Human writing uses those much more sparingly and doesn’t separate them into two sentences as often. It has a lot of “subject change: teaser” constructions, too. And overuse of bold and restatement.

Could it be human? Sure. But it doesn’t seem likely to me.

anon48293•about 2 hours ago

It didn’t read AI generated to me. I also love the irony of then using AI to generate a summary

hyperpape•about 1 hour ago

> This article is the story of chasing that number down to a single machine instruction, and then finding out that the instruction was only half of the answer.

> So the difference has to be in what the JIT generated, and the profiler gives us exactly that.

> That is the whole vocabulary. Let’s read some code.

> Decoding the x86 version instruction by instruction is out of scope here.

> What is not architecture specific is the logic.

Here’s a segment flagged by Pangram: https://www.pangram.com/history/87e25169-30a4-4030-a65a-dba8...

a2ff6eeb0•31 minutes ago

If you don't like AI writing, why are you on hacker news? Most of the articles posted are written by AI.

deathanatos•13 minutes ago

Some of us have been here longer than AI. "To be intellectually stimulated" would be the why, which there used to be more of prior to the frontpage becoming riddled with AI slop. "HN is for conversation between humans" as the guidelines say, and though the guidelines imply that's towards comments, I'd prefer it to be towards submissions too, for the same reasons it was added for comments.

I'm already at the point of "the reward/effort of HN is getting pretty low", but the question is, where to leave for?

pron•about 1 hour ago

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

marginalia_nu•31 minutes ago

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.

cogman10•24 minutes ago

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

Why is Arrays.fill 265 times slower on G1GC?

⚡ Community Insights

Discussion (14 Comments)Read Original on HackerNews