> Ok, just glanced at my corp workstation and some Java build analysis server is using 25GB RES, 50GB VIRT when I have no builds going. The hell is it doing.
Allocating a heap of the size it was configured to use, probably.
Re:Memory Safety Is Merely Table Stakes
by frollogaston on Friday June 27, 2025 @12:11AM
(#44393643)
That's a max size, not a preset allocation. The process normally starts out using 1GB.
Sure, but if it's had to use a lot at some point in the past it usually holds onto it.
Re:Memory Safety Is Merely Table Stakes
by frollogaston on Friday June 27, 2025 @01:28AM
(#44393923)
That would explain it, but also, that's super broken
Nothing broken about it. It's optimized for a particular situation, that situation being a long running process on a server. This is where the JVM typically runs. If you don't want that behaviour there are a myriad of GC options, which could be better documented but are not that hard to find.
Re:Memory Safety Is Merely Table Stakes
by frollogaston on Friday June 27, 2025 @12:08PM
(#44397902)
I'm not the one who wrote it though, and it's software designed to run on a workstation.
It's not a big issue for a server deployment where if you got that memory from the OS and didn't get killed, there's probably nothing else running on the box and you might as well keep it for the next traffic spike. But yeah not ideal on the desktop/workstation.
Re:Memory Safety Is Merely Table Stakes
by AlotOfReading on Thursday June 26, 2025 @08:45PM
(#44392876)
More of a historical footnote than a serious example, but you've never had to kill the Java applications running on your SIM card (or eSIM).
Re:Memory Safety Is Merely Table Stakes
by frollogaston on Thursday June 26, 2025 @08:47PM
(#44392884)
I don't know about that, my flip phone used to crash quite often. And it displayed a lot of Java logos.
Re:Memory Safety Is Merely Table Stakes
by AlotOfReading on Thursday June 26, 2025 @09:02PM
(#44392944)
Different processor and JVM. My understanding is that early versions of the Java card runtime didn't even support garbage collection. It was a very different environment to program, even if the language was "Java".
Re:Memory Safety Is Merely Table Stakes
by cherrycherry98 on Friday June 27, 2025 @01:12AM
(#44393865)
GC usually only runs when the process wants to allocate an object but there's no space left on the heap. It's entirely possible that it did a bunch of work previously which created a bunch of garbage now waiting to be cleaned up. See the G1PeriodicGCInterval flag to enable idle collections (assuming G1).
Java is also fairly greedy with memory by default. It likes to grow the heap and then hold onto that memory unless 70% of the heap is free after a collection. The ratios used to grow and shrink the heap can be tuned with MinHeapFreeRatio and MaxHeapFreeRatio.
Re:Memory Safety Is Merely Table Stakes
by andreasmetsala on Friday June 27, 2025 @07:50AM
(#44396029)
Why do Java developers still have to tune stuff like that?
Re:Memory Safety Is Merely Table Stakes
by frollogaston on Tuesday July 01, 2025 @09:06PM
(#44439368)
Before I even went on my rant, I was guessing there's just some confusing default like this but there's also some historical reason why it's like that.
Re:Memory Safety Is Merely Table Stakes
by adgjlsfhk1 on Friday June 27, 2025 @02:48AM
(#44394291)
don't slander the Prius! it's an incredibly efficient and robust machine. Java is a Chevy Colerado. surprisingly common for how unreliable it is
Re:Memory Safety Is Merely Table Stakes
by frollogaston on Friday June 27, 2025 @03:48PM
(#44399725)
That's what I mean, surely the Prius can reach 100mph, but you rarely see it go past 55. Usually in the fast lane. It's a paradox.
Ok, just glanced at my corp workstation and some Java build analysis server is using 25GB RES, 50GB VIRT when I have no builds going. The hell is it doing.