7 ms·

> baseline memory usage for common types of Java service is 1 GB, vs 50 MB for Go. There's nothing inherent to the JVM that'd need 1GB of memory footprint - th

• shizcakes 7y ago
  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.
• geodel 7y ago
  > it is very easy to use more but many J2EE apps can be made to work with a Gig and you do get a lot of features for that. It like I see in US a 4-person family can be made to fit in 5000 sq ft home and even with such space crunch you can have lot of features in home.
  • deleted 7y ago
    [deleted]
  • hibbelig 7y ago
    5000 sq ft?? My family of four lives in 1000 and it’s only a bit cramped. Each kid has their own room. I knew homes in the US are larger than in Europe but I’m surprised about the difference.
    • blinkingled 7y ago
      I live in the US and 5000 sq ft is unheard of even in most affordable of all places. 3000 is more like it - still big but only in cheaper places. As you get to costlier real estate markets 1800 sq ft is not uncommon.
    • winstonewert 7y ago
      I think that's their point? 1 Gig of memory for a java app is like 5000 sq ft for four people.
      • hibbelig 7y ago
        Thank you. I didn't read it that way. Makes a lot of sense.
    • deleted 7y ago
      [deleted]
    • bcrosby95 7y ago
      New houses for a family of 6 tend to be 2300-3000 sq feet. I live in an older house with a family of 6 that is 1800 sq feet. 5,000 sq feet built for a family of 4 tends to be limited to penthouse suites that cost tens of millions of dollars.
• seriesf 7y ago
  I’ve seen applications that need more than 256MB just for compiled code cache.