Re:Java at 30: The Genius Behind the Code That Changed Tech
by zdragnar on Saturday May 17, 2025 @11:04AM
(#44014850)
Is data access in such a project purely from in-memory sources? I suspect most people shun it because database access- especially if the DB itself is over the network on a different machine- already slow enough that ZGC / zero allocation won't be noticed.
Re:Java at 30: The Genius Behind the Code That Changed Tech
by znpy on Sunday May 18, 2025 @04:50AM
(#44019947)
> Is data access in such a project purely from in-memory sources?
yes.
> I suspect most people shun it because database access- especially if the DB itself is over the network on a different machine- already slow enough that ZGC / zero allocation won't be noticed.
Database access, if you're talking network latency query/transaction processing time, is essentially irrespective of the language being used, so that's not a good reason to shun Java as a language/rutime anyway.
Re:Java at 30: The Genius Behind the Code That Changed Tech
by zdragnar on Sunday May 18, 2025 @02:05PM
(#44023217)
Oh, I'm not talking about shunning Java, but the zero-allocation style of coding while using Java.
If you have the extra network latency from external services, you need some pretty outrageous traffic for GC to become a problem, I would think.
I think that's mostly done in organisation where there's time, budget and willingness to optimize as far as possible.
Sacrificing the guardrails doesn't make sense for the "general public" software but does tremendous sense in environment where latency is critical and the scale is massive. But then again, in those environments there are people handsomely paid to have a thorough understanding of the software and keep it working (making updates, implementing features etc).
I worked on a software that was written to be garbage-free whenever it could. Latency (server-side latency, i mean) in production (so real-world use case, not synthetic benchmark) was about 7-8 microseconds per request (p99.9) and STW garbage collection was at around 5msec (G1GC, p50, mostly young generation) or ~40 msec (p99.9, full gc) and was later lowered to ~800-900 microseconds with ZGC.
I know it might sound elitist but the real difference here are... Skill issues. Some people will just shun java down and yap about rewriting in rust or something like that, while some other people will benefit from the already existing Java ecosystem (and tooling) and optimize what they need to get the speed they're targeting.
I know I'll be downvoted by the rust evangelism task force, but meh.