5 ms·

This is really odd. One of the biggest criticisms of Java is that it consumes so much memory, for which the rebuttal is the JVM can be tuned to use less! But no

This is really odd. One of the biggest criticisms of Java is that it consumes so much memory, for which the rebuttal is the JVM can be tuned to use less! But no one does this in practice, so I assume there must be a reason that renders the “tuning” argument to be penny wise and pound foolish. I.e., you end up giving up something more valuable in exchange for that lower memory value. It seems like these Java apologists are trying to give the appearance that Java competes with (for example) Go in memory usage and startup performance and runtime performance when in reality it’s probably more like “you get to choose one of the three”, especially with respect to the top level comment about how the AOT story deceptively requires hidden tradeoffs.

jghn 7y ago
Most people done care enough to put in the effort to tune their application
meddlepal 7y ago
Most developers don't think about tuning the runtime because performance is not one of their acceptance criteria... at best what happens is you have a JVM savvy ops engineer who looks at it in production and recommends some tuning options... these often then get rejected by the devs because they don't understand the features and are afraid tweaking things will break and cause them problems. So they tell the ops team to throw more/bigger servers at the problem.
brazzy 7y ago
> One of the biggest criticisms of Java is that it consumes so much memory, for which the rebuttal is the JVM can be tuned to use less! But no one does this in practice, so I assume there must be a reason that renders the “tuning” argument to be penny wise and pound foolish Nope, the main reason is simply that memory is cheap and plentiful, so there is simply no reason to spend any effort to tune base memory usage when writing the kind of applications Java is typically used for.
miskin 7y ago
In late 90s I ran our JUG website with homegrown CMS written in Java with servlets on slackware linux server running also MySQL and it had only 16MB of physical memory for everything. We are _very_ spoiled nowadays and tuning is simply not necessary for most of tasks.
EdwardDiego 7y ago
We repeatedly tune our JVM apps to acquire only memory they need, so we can run more apps on the same machine, and thus pay less.
- cbsmith 7y ago
  "nobody" was deliberately an overly extreme statement. As implied by my statement, obviously some people do tune their apps, but the people complaining that the JVM needs gigabytes of memory just to run are clearly not in that group.
barrkel 7y ago
The current default collector doesn't give memory back to the OS. So if you have several peaky memory usage apps, you can't try and get them to elastically negotiate heap size tradeoffs with one another - you need to pack them in with max heap limits manually. That requires a lot of tuning, and it's still less than theoretically optimal. We fork a child JVM to run our peakiest jobs for just this reason. Also help keep services up when something OOMs.
- cbsmith 7y ago
  > The current default collector doesn't give memory back to the OS. That's a pretty irrelevant point, as the current default collector in Sun's JVM does reduce the Java heap based on tuneable parameters. While it doesn't return the virtual address space to the OS, that generally doesn't impact memory consumption on the "current default" OS's. (Certainly there are specialized cases where you might care about that, and for that there are other collectors and other JVM's for that matter.) > So if you have several peaky memory usage apps, you can't try and get them to elastically negotiate heap size tradeoffs with one another - you need to pack them in with max heap limits manually. That's simply not true. The default GC does adjust heap size based on utilization, so you absolutely can run peaky apps that manage to negotiate different times for their peaks in a constrained memory space. > We fork a child JVM to run our peakiest jobs for just this reason. Well, I guess that's one way to address the problem, but you've unfortunately misunderstood how your tool works.
  - barrkel 7y ago
    > Well, I guess that's one way to address the problem, but you've unfortunately misunderstood how your tool works. No, I don't think you have the context. The peaky process will be killed for OOM by Linux; we explicitly don't want services to die, which they would if they lived in the same process. So, the services live in the parent process, and the peaky allocation happens in the child process. For context, at steady state the services consume about 2GB, whereas the peaky process may consume 30GB for 30 minutes or a couple of hours. We use resource-aware queuing / scheduling to limit the number of these processes running concurrency. It's true that G1 will, under duress (e.g. under micro-benchmark scenarios with explicit calls to System.gc()), give up some heap to the OS, but it's not what you see in practice, without exceptional attention paid to tuning. Process exit is particularly efficient as a garbage collector though.
michaelmrose 7y ago
If the full amount paid for your developer including office space, taxes, salary, benefits is 200k which pays for 48 weeks x 40 hours you are paying 104 dollars per hour. Ram probably costs you 2 to 4 dollars per gb. Saving 1gb memory is worth it if it does not cost your developer more than 2 minutes to figure out.
- weberc2 7y ago
  RAM is billed by the hour (or minute?) by cloud providers, and it’s 1GB per process, not 1GB total. If you’re running 20 virtual servers, that’s 20 GB. Moreover, if you’re shipping a desktop app, it’s 1GB * number of licenses. Finally, the “it’s not worth tuning” argument proves my point—Java proponents will tell you that Java doesn’t need to consume that much memory—you just have to tune it, but no one tunes it because it’s too hard/not worth it.
  - miskin 7y ago
    But this, of course, applies to every project in any language and is in no way limited to Java or OOP. It is always balance between delivering functionality now with some solution or later MAYBE better optimized. Then in round two, optimized solution may be harder to maintain and extend, or further optimization may be de-prioritized to some new functionality with higher business value. We all know it. You are trying to project your belief to all Java applications and this simply does not work. There are both good apps and not good apps and there are many metrics to evaluate "good".
    - weberc2 7y ago
      It appears to be specific to Java. Other languages don’t seem to exhibit high memory usage with the same frequency or severity as Java, and that’s not because developers of other languages spend more time optimizing. If indeed this observed memory bloat is just a matter of poorly written Java apps, then that’s even more interesting. Why does it seem like Java has such a high incidence of poorly written apps relative to other languages? Is it OOP or some other cultural element?
cbsmith 7y ago
I think you misunderstand. The argument is simply that if it were as important as some suggest it is, there'd be an effort to use memory much more efficiently. Java does run on incredibly small memory footprints, but the runtime that most people use deliberately trades memory for other advantages, and even then people choose to operate with far more memory than it requires. That seems like empiricle evidence that other factors are far more important.

jghn 7y ago

Most people done care enough to put in the effort to tune their application

meddlepal 7y ago

Most developers don't think about tuning the runtime because performance is not one of their acceptance criteria... at best what happens is you have a JVM savvy ops engineer who looks at it in production and recommends some tuning options... these often then get rejected by the devs because they don't understand the features and are afraid tweaking things will break and cause them problems. So they tell the ops team to throw more/bigger servers at the problem.

brazzy 7y ago

> One of the biggest criticisms of Java is that it consumes so much memory, for which the rebuttal is the JVM can be tuned to use less! But no one does this in practice, so I assume there must be a reason that renders the “tuning” argument to be penny wise and pound foolish Nope, the main reason is simply that memory is cheap and plentiful, so there is simply no reason to spend any effort to tune base memory usage when writing the kind of applications Java is typically used for.

miskin 7y ago

In late 90s I ran our JUG website with homegrown CMS written in Java with servlets on slackware linux server running also MySQL and it had only 16MB of physical memory for everything. We are _very_ spoiled nowadays and tuning is simply not necessary for most of tasks.

EdwardDiego 7y ago

We repeatedly tune our JVM apps to acquire only memory they need, so we can run more apps on the same machine, and thus pay less.

cbsmith 7y ago
"nobody" was deliberately an overly extreme statement. As implied by my statement, obviously some people do tune their apps, but the people complaining that the JVM needs gigabytes of memory just to run are clearly not in that group.

barrkel 7y ago

The current default collector doesn't give memory back to the OS. So if you have several peaky memory usage apps, you can't try and get them to elastically negotiate heap size tradeoffs with one another - you need to pack them in with max heap limits manually. That requires a lot of tuning, and it's still less than theoretically optimal. We fork a child JVM to run our peakiest jobs for just this reason. Also help keep services up when something OOMs.

cbsmith 7y ago
> The current default collector doesn't give memory back to the OS. That's a pretty irrelevant point, as the current default collector in Sun's JVM does reduce the Java heap based on tuneable parameters. While it doesn't return the virtual address space to the OS, that generally doesn't impact memory consumption on the "current default" OS's. (Certainly there are specialized cases where you might care about that, and for that there are other collectors and other JVM's for that matter.) > So if you have several peaky memory usage apps, you can't try and get them to elastically negotiate heap size tradeoffs with one another - you need to pack them in with max heap limits manually. That's simply not true. The default GC does adjust heap size based on utilization, so you absolutely can run peaky apps that manage to negotiate different times for their peaks in a constrained memory space. > We fork a child JVM to run our peakiest jobs for just this reason. Well, I guess that's one way to address the problem, but you've unfortunately misunderstood how your tool works.
- barrkel 7y ago
  > Well, I guess that's one way to address the problem, but you've unfortunately misunderstood how your tool works. No, I don't think you have the context. The peaky process will be killed for OOM by Linux; we explicitly don't want services to die, which they would if they lived in the same process. So, the services live in the parent process, and the peaky allocation happens in the child process. For context, at steady state the services consume about 2GB, whereas the peaky process may consume 30GB for 30 minutes or a couple of hours. We use resource-aware queuing / scheduling to limit the number of these processes running concurrency. It's true that G1 will, under duress (e.g. under micro-benchmark scenarios with explicit calls to System.gc()), give up some heap to the OS, but it's not what you see in practice, without exceptional attention paid to tuning. Process exit is particularly efficient as a garbage collector though.

michaelmrose 7y ago

If the full amount paid for your developer including office space, taxes, salary, benefits is 200k which pays for 48 weeks x 40 hours you are paying 104 dollars per hour. Ram probably costs you 2 to 4 dollars per gb. Saving 1gb memory is worth it if it does not cost your developer more than 2 minutes to figure out.

weberc2 7y ago
RAM is billed by the hour (or minute?) by cloud providers, and it’s 1GB per process, not 1GB total. If you’re running 20 virtual servers, that’s 20 GB. Moreover, if you’re shipping a desktop app, it’s 1GB * number of licenses. Finally, the “it’s not worth tuning” argument proves my point—Java proponents will tell you that Java doesn’t need to consume that much memory—you just have to tune it, but no one tunes it because it’s too hard/not worth it.
- miskin 7y ago
  But this, of course, applies to every project in any language and is in no way limited to Java or OOP. It is always balance between delivering functionality now with some solution or later MAYBE better optimized. Then in round two, optimized solution may be harder to maintain and extend, or further optimization may be de-prioritized to some new functionality with higher business value. We all know it. You are trying to project your belief to all Java applications and this simply does not work. There are both good apps and not good apps and there are many metrics to evaluate "good".
  - weberc2 7y ago
    It appears to be specific to Java. Other languages don’t seem to exhibit high memory usage with the same frequency or severity as Java, and that’s not because developers of other languages spend more time optimizing. If indeed this observed memory bloat is just a matter of poorly written Java apps, then that’s even more interesting. Why does it seem like Java has such a high incidence of poorly written apps relative to other languages? Is it OOP or some other cultural element?

cbsmith 7y ago

I think you misunderstand. The argument is simply that if it were as important as some suggest it is, there'd be an effort to use memory much more efficiently. Java does run on incredibly small memory footprints, but the runtime that most people use deliberately trades memory for other advantages, and even then people choose to operate with far more memory than it requires. That seems like empiricle evidence that other factors are far more important.