11 ms·

You're almost certainly right about Xms being set to 1GB. However, even if you can experimentally set it lower, the first time the JVM app hits GC pressure, the

You're almost certainly right about Xms being set to 1GB. However, even if you can experimentally set it lower, the first time the JVM app hits GC pressure, the first thing anyone is going to try is bumping that back up over 1GB to give it some breathing room. Memory may be "cheap", but wasting 950MB of memory per process because the GC might flip out at the wrong time isn't cheap when you multiply it out to many processes. Also, I find the claim that the JVM starts and is running in 90ms very dubious. I would like to see an all-in timer, something like run each in a container, and see which completes first from container startup to shutdown.

blinkingled 7y ago
> first time the JVM app hits GC pressure, the first thing anyone is going to try is bumping that back up over 1GB to give it some breathing room. Yeah but in that case your app legitimately needs that much. Not the JVM. Secondly unless your app is extremely performance sensitive setting Xms to lower value doesn't make the GC flip out - it's not as if the GC is going to collect repeatedly to stay within your lower bound - on the contrary it will expand the heap upwards until Xmx limit. Sure there will be a cost to expand the heap above Xms up to Xmx but it is not at all significant due to how clever the GC is.
- harlanji 7y ago
  The OS tells processes when it needs resources freed and the JVM will tidy up then. Otherwise it’s lazy and that is correct. A JVM can run on 10s of MB of RAM and start in milliseconds. This is as-of JVM 8 that’s why vague, years ago, and it should only be better now if modules are in.
  - ptx 7y ago
    The module system actually makes start-up slower (the designers admitted in some presentation) because of the checks it has to perform. Java 9 was a lot slower than 8 and subsequent versions have gotten better but are still slower than 8.
    - apta 7y ago
      https://cl4es.github.io/2019/11/20/OpenJDK-Startup-Update.html https://cl4es.github.io/2019/11/20/OpenJDK-Startup-Update.ht...
      - ptx 7y ago
        Those numbers are without CDS on Java 8. This is what I get on my machine – Java 13 is 10% faster than Java 8 if you use a jlinked JRE, or 15% slower otherwise: $ JAVA=/usr/lib/jvm/java-8-openjdk/bin/java; for i in {1..100}; do time -p "$JAVA" -Xshare:on Hello; done 2>&1|grep real|awk 'BEGIN { sum=0 } { sum += $2 } END { print 1000 * sum / NR " ms" }' 90.7 ms $ JAVA=/usr/lib/jvm/java-13-openjdk/bin/java; for i in {1..100}; do time -p "$JAVA" -Xshare:on Hello; done 2>&1|grep real|awk 'BEGIN { sum=0 } { sum += $2 } END { print 1000 * sum / NR " ms" }' 106.4 ms $ JAVA=/tmp/jlinked-java13-jre/bin/java; for i in {1..100}; do time -p "$JAVA" -Xshare:on Hello; done 2>&1|grep real|awk 'BEGIN { sum=0 } { sum += $2 } END { print 1000 * sum / NR " ms" }' 82.3 ms Interestingly, Java 7 is faster than any of the newer versions. $ JAVA=/usr/lib/jvm/java-7-openjdk/bin/java; for i in {1..100}; do time -p "$JAVA" -Xshare:on Hello; done 2>&1|grep real|awk 'BEGIN { sum=0 } { sum += $2 } END { print 1000 * sum / NR " ms" }' 80.6 ms ...and Java 6 is even faster: $ JAVA=/opt/java6/bin/java; for i in {1..100}; do time -p "$JAVA" -Xshare:on Hello; done 2>&1|grep real|awk 'BEGIN { sum=0 } { sum += $2 } END { print 1000 * sum / NR " ms" }' 62.2 ms So I appreciate that they're finally working on the startup performance regressions, but they apparently have some way to go before achieving parity with the famously lightning-fast startup time of older Java releases.
cbsmith 7y ago
What's funny about these comments is that I originally ran the JVM on machines with something 16MB of RAM, and I've run it on smaller devices with much less RAM. ;-) You can run the JVM on very small heaps. It's just that nobody does.
- weberc2 7y ago
  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.
solarengineer 7y ago
To understand numbers on specific hardware, I have in the past started Tomcat bare (not even the manager app), and then Tomcat with my specific web app. The startup time has indeed been in the milliseconds ( I happen to embed Tomcat in products so I have had to understand such things). In my use cases, startup time has been of less importance than execution time, the JIT pause, and the GC pauses. So I tend to run the jvm is server mode.

blinkingled 7y ago

> first time the JVM app hits GC pressure, the first thing anyone is going to try is bumping that back up over 1GB to give it some breathing room. Yeah but in that case your app legitimately needs that much. Not the JVM. Secondly unless your app is extremely performance sensitive setting Xms to lower value doesn't make the GC flip out - it's not as if the GC is going to collect repeatedly to stay within your lower bound - on the contrary it will expand the heap upwards until Xmx limit. Sure there will be a cost to expand the heap above Xms up to Xmx but it is not at all significant due to how clever the GC is.

harlanji 7y ago
The OS tells processes when it needs resources freed and the JVM will tidy up then. Otherwise it’s lazy and that is correct. A JVM can run on 10s of MB of RAM and start in milliseconds. This is as-of JVM 8 that’s why vague, years ago, and it should only be better now if modules are in.
- ptx 7y ago
  The module system actually makes start-up slower (the designers admitted in some presentation) because of the checks it has to perform. Java 9 was a lot slower than 8 and subsequent versions have gotten better but are still slower than 8.
  - apta 7y ago
    https://cl4es.github.io/2019/11/20/OpenJDK-Startup-Update.html https://cl4es.github.io/2019/11/20/OpenJDK-Startup-Update.ht...
    - ptx 7y ago
      Those numbers are without CDS on Java 8. This is what I get on my machine – Java 13 is 10% faster than Java 8 if you use a jlinked JRE, or 15% slower otherwise: $ JAVA=/usr/lib/jvm/java-8-openjdk/bin/java; for i in {1..100}; do time -p "$JAVA" -Xshare:on Hello; done 2>&1|grep real|awk 'BEGIN { sum=0 } { sum += $2 } END { print 1000 * sum / NR " ms" }' 90.7 ms $ JAVA=/usr/lib/jvm/java-13-openjdk/bin/java; for i in {1..100}; do time -p "$JAVA" -Xshare:on Hello; done 2>&1|grep real|awk 'BEGIN { sum=0 } { sum += $2 } END { print 1000 * sum / NR " ms" }' 106.4 ms $ JAVA=/tmp/jlinked-java13-jre/bin/java; for i in {1..100}; do time -p "$JAVA" -Xshare:on Hello; done 2>&1|grep real|awk 'BEGIN { sum=0 } { sum += $2 } END { print 1000 * sum / NR " ms" }' 82.3 ms Interestingly, Java 7 is faster than any of the newer versions. $ JAVA=/usr/lib/jvm/java-7-openjdk/bin/java; for i in {1..100}; do time -p "$JAVA" -Xshare:on Hello; done 2>&1|grep real|awk 'BEGIN { sum=0 } { sum += $2 } END { print 1000 * sum / NR " ms" }' 80.6 ms ...and Java 6 is even faster: $ JAVA=/opt/java6/bin/java; for i in {1..100}; do time -p "$JAVA" -Xshare:on Hello; done 2>&1|grep real|awk 'BEGIN { sum=0 } { sum += $2 } END { print 1000 * sum / NR " ms" }' 62.2 ms So I appreciate that they're finally working on the startup performance regressions, but they apparently have some way to go before achieving parity with the famously lightning-fast startup time of older Java releases.

cbsmith 7y ago

What's funny about these comments is that I originally ran the JVM on machines with something 16MB of RAM, and I've run it on smaller devices with much less RAM. ;-) You can run the JVM on very small heaps. It's just that nobody does.

weberc2 7y ago
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.

solarengineer 7y ago

To understand numbers on specific hardware, I have in the past started Tomcat bare (not even the manager app), and then Tomcat with my specific web app. The startup time has indeed been in the milliseconds ( I happen to embed Tomcat in products so I have had to understand such things). In my use cases, startup time has been of less importance than execution time, the JIT pause, and the GC pauses. So I tend to run the jvm is server mode.