3 ms·

> That's tough to figure out. Indeed. That fact obviates this option in most cases. You have to spend time tweaking obscure, unstable knobs (the X in Xmx mea

> That's tough to figure out. Indeed. That fact obviates this option in most cases. You have to spend time tweaking obscure, unstable knobs (the X in Xmx means Oracle is free to alter its meaning at any time) and risk either a.) serious failures in production or b.) poor results because the conservative choices necessary to avoid 'a' achieved little improvement and you wasted your time. The real world for most enterprises is a vast heard of communicating components and toying with GC switches multiplied by N things is a nonstarter. So while you're technically correct that excessive memory use by conventional JVMs is "not always true," in practice you are wrong. That reality comes with a real cost that appears on a real bill every single month.

throwaway189262 6y ago
The cost of setting a few command line args? They're not really obscure or unstable, just different depending on the GC you use. Turning on ZGC and setting the right options is like 4 command line flags. It's very easy, the reason it's not frequently done is that nobody reads documentation and it's not the default. Go's approach of minimal knobs leads to unfixable problems in production. Java gives more options to tune GC for your use case
- topspin 6y ago
  > Go's approach of minimal knobs leads to unfixable problems in production. I didn't bring up Go, but since you did the thing I see is that Go -- a much younger language -- is going places Java never has, or did so only haltingly. Caddy is a case in point. Here is Go taking on nginx, haproxy, Envoy, etc. The people that once imagined using Java for such things have retired or moved on to other battles. No one seriously ponders attempting 'systems' tasks with Java any longer; that whole space was ceded to more efficient languages. My opinion is that Java's poor efficiency -- a big part of which is its excessive memory consumption -- is the reason for this. That's my opinion. What I know for fact is that today, when people are making design decisions about new services and their deployment, Java is a problem; it is understood that anything implemented in Java is going to sort right to the top of the list of memory pigs in the cluster, and you can only afford so many of those.
- imtringued 6y ago
  I think you're ignoring that people don't want to "tune" their GC. They just want it to work. So instead, they are going with the obvious route of just buying more RAM. This is perfectly fine on servers, which is where Java shines. As soon as Java has to be used for e.g. CLI scripts, daemons, or situations in which multiple process instances have to run at the same time, then Java is an incredibly poor choice and there is nothing you can do about that. If you are a genius at memory optimization in Java then you'll see even bigger gains in C++ or Go or Lua or Javascript or Python. Some of these options may not be as fast as the JVM but this discussion is purely about memory usage.

throwaway189262 6y ago

The cost of setting a few command line args? They're not really obscure or unstable, just different depending on the GC you use. Turning on ZGC and setting the right options is like 4 command line flags. It's very easy, the reason it's not frequently done is that nobody reads documentation and it's not the default. Go's approach of minimal knobs leads to unfixable problems in production. Java gives more options to tune GC for your use case

topspin 6y ago
> Go's approach of minimal knobs leads to unfixable problems in production. I didn't bring up Go, but since you did the thing I see is that Go -- a much younger language -- is going places Java never has, or did so only haltingly. Caddy is a case in point. Here is Go taking on nginx, haproxy, Envoy, etc. The people that once imagined using Java for such things have retired or moved on to other battles. No one seriously ponders attempting 'systems' tasks with Java any longer; that whole space was ceded to more efficient languages. My opinion is that Java's poor efficiency -- a big part of which is its excessive memory consumption -- is the reason for this. That's my opinion. What I know for fact is that today, when people are making design decisions about new services and their deployment, Java is a problem; it is understood that anything implemented in Java is going to sort right to the top of the list of memory pigs in the cluster, and you can only afford so many of those.
imtringued 6y ago
I think you're ignoring that people don't want to "tune" their GC. They just want it to work. So instead, they are going with the obvious route of just buying more RAM. This is perfectly fine on servers, which is where Java shines. As soon as Java has to be used for e.g. CLI scripts, daemons, or situations in which multiple process instances have to run at the same time, then Java is an incredibly poor choice and there is nothing you can do about that. If you are a genius at memory optimization in Java then you'll see even bigger gains in C++ or Go or Lua or Javascript or Python. Some of these options may not be as fast as the JVM but this discussion is purely about memory usage.