Re:Java 25's new CPU-Time Profiler (1)
by vladgur on Saturday September 13, 2025 @08:15PM
(#45236397)
When is FFM going to be production ready?
Re:Java 25's new CPU-Time Profiler (1)
by spreiti on Saturday September 13, 2025 @10:57PM
(#45237037)
Since JDK 22 https://openjdk.org/jeps/454
Re:Java 25's new CPU-Time Profiler (1)
by creata on Saturday September 13, 2025 @06:32PM
(#45235846)
Sorry if this is a stupid question, but does this argument continue to make sense for desktop applications, which don't typically use much CPU unless they're currently focused, but do use the same amount of RAM regardless of whether they're focused?
Then you'd be happy to learn that it's been superseded by FFM: https://openjdk.org/jeps/454 (not in all situations, but in almost all).
> The second biggest knock is that the JVM is still kind of a memory pig
I would strongly recommend watching this keynote from this year's ISMM (International Symposium on Memory Management) on this very subject: https://www.youtube.com/watch?v=mLNFVNXbw7I
The long and short of it is that (and I'm oversimplifying the talk, of course) if you use less than 1GB of RAM per CPU core, then you're likely trading off CPU for RAM in a way that's detrimental, i.e. you're wasting a valuable resource (CPU) to save a resource (RAM) that you can't put to good use (because the amount of work you can do on a machine is determined by the first of these resources to be exhausted, so you should use them in the ratio they're provided by the hardware). Refcounting collectors and even manual memory management (unless you're using arenas almost exclusively) optimise for memory footprint at the expense of CPU. Put another way, the JVM takes advantage of the more plentiful RAM to save on the more costly CPU.