so its not memory efficient then...and nowadays the bottleneck is in memory access not cpu cycles, so the claim more memory use speeds up compute is very doubtful
For a definition of "efficient" that isn't shared by anyone else. This isn't a new rationale either, but a well known trade-off involved with JIT compilation and garbage collection. It's the reason Chrome "hogs" memory and Firefox is perceived as slow: they make different resource usage tradeoffs.
It will be interesting to see if the current memory crunch will impact this calculus going forward.
FF seems to use less RAM than Chrome for my 100+ open tabs these days. It’s just as fast for 99% of sites and surprisingly even compatibility is often better. Half the time when my wife encounters a broken webapp in Chrome it works fine when I have her try in FF.
> But what's the point in leaving available memory on the table if using it makes your program run faster? Efficient use of that resource wouldn't be to leave it untapped but to use it to speed up the program.
What’s the point of having a host with available memory? In today’s clouds, couldn’t you just downsize the host, and save on cost?
I agree with all the general principles, but the details of Java do matter here. There is a reason they're working hard on Project Valhalla: https://openjdk.org/projects/valhalla/
Java was designed to make manual memory management a non-concern. Yet, ironically, it's the runtime that require more explicit memory tuning than any others.
This does not match my experience. The amount of manual tuning needed for memory management in C/C++ (which Java was designed to improve upon) was orders of magnitude greater than with Java just to get it correct, let alone efficient in terms of memory usage and performance.
Sure, a few examples that happen with modern JVMs (even 25). Essentially anything addressing a large amount of memory (think > 100gb). This can be databases, streaming solutions and so on, where you start tuning the GC just to have a smooth experience. Then there is the case of memory fragmentation of the heap, so you might want to switch out your GC. What else, basically any system that uses a lot of temporary memory is borked, because Java has a nasty habit of not returning unused heap to the OS by default. All in all, my point is, if you are doing anything that actually utilizes the hardware near its limits you will be tuning by quite a bit.
> All in all, my point is, if you are doing anything that actually utilizes the hardware near its limits you will be tuning by quite a bit.
What do you think happens in case of literally any other platform/programming language when you go near the limit? You are just either forced to change code, or.. well just put up your hand in the air, I guess and maybe buy better hardware?
20 comments
[ 0.18 ms ] story [ 10.6 ms ] threadIt will be interesting to see if the current memory crunch will impact this calculus going forward.
What’s the point of having a host with available memory? In today’s clouds, couldn’t you just downsize the host, and save on cost?
- Ignorance is strength
- Java is memory efficient
For 90% of workflows you don't add any command line arguments, for the remaining 10% you may specify a heap size. That's all.
What do you think happens in case of literally any other platform/programming language when you go near the limit? You are just either forced to change code, or.. well just put up your hand in the air, I guess and maybe buy better hardware?