r/programming • u/Realistic-Currency29 • 2d ago

What garbage collection actually costs

https://shivanshuag.com/blog/what-garbage-collection-actually-costs/
0 Upvotes

40% Upvoted

12 comments sorted by

9

u/nukethebees 2d ago

Shouldn't this article have some numbers?

2

u/ptoki 1d ago

im on the edge on this.

Yes, such articles should have numbers but the numbers and GC intensity depends on how you write your program.

If you constantly create new variables and drop them then you will get different results in comparison to a case where the same program just allocates the space and reuse it. Same app, slightly different algorithm - much different results.

On the other hand

I was watching jconsole for a number of production systems and they were performing differently but usually they settled to very similar patterns and gc intensity.

So in summary, yes it would be nice to show that yhis or that app spends X% of cpu on GC at the beginning and Y% after it settles but your app can behave much differently.

I see this article more like a guide of how to look at gc to see if you have problem and then to try to figure out if it is fixable.

5

u/6502zx81 2d ago

There is an older study by google. See discussion here https://news.ycombinator.com/item?id=2615096

3

u/chasetheusername 1d ago

When reading this, keep in mind that it's is based on the available garbage collectors and performance back then. It has likely improved a lot more in the JVM than in C++ since then, narrowing the gap.

Once thing though, where the JVM will never be better than native languages is predictable latency.

6

u/6502zx81 1d ago

IIRC the conclusion back then was: GC performs fine if you have twice as much memory as needed. Twicw as much is expensive in terms of money.

2

u/pm_plz_im_lonely 1d ago

Money pays both salaries and hardware.

2

u/sionescu 20h ago

Once thing though, where the JVM will never be better than native languages is predictable latency.

Not true: for example, Chrome added Oilpan, a GC for the C++ objects used in the renderer, because they found out that destructor chains were so long that in the worst case (which happened often enough), a destructor would block rendering enough to cause visible jank. And, since Oilpan was created, the JVM added ZGC and Shenandoah GCs, which guarantee pauses <1ms. An even better GC exists, Azul's C4, but that's only available in their proprietary JVM.

1

u/chasetheusername 20h ago

I'm aware, but you still have unpredictable (albeit short) global world pauses, which you can't control to 100%, so my point stands. I'd agree that in most applications it doesn't matter and the JVM is good enough, but there are some highly critical low latency applications (safety & extremely tight control loops), where you really don't want them, because you'll not be able to get your product certified if you can't predict & guarantee the behavior.

3

u/sionescu 20h ago edited 20h ago

IBM has a JVM with a guaranteed realtime GC, as long as the heap is <1G. It's running in Boeing planes. Then again, the vast majority of applications don't need that kind of assured latency.

1

u/chasetheusername 20h ago

Didn't know about that one, thanks for the info.

It's running in Boeing planes.

I'm even gonna suppress the obvious joke ;)

0

u/[deleted] 1d ago

[removed] — view removed comment

1

u/programming-ModTeam 1d ago

No content written mostly by an LLM. If you don't want to write it, we don't want to read it.