It's hard to square these articles with the reality I see on the ground: our baseline memory usage for common types of Java service is 1 GB, vs 50 MB for Go. We do have a few mammoth servers at the top end in both languages though (e.g. 75 GB heaps)<p>The deploy JARs have 100+ MB of class files, so perhaps it's a function of all the dependencies that you "need" for an enterprise Java program and not something more fundamental.<p>These blog posts also present AOT as if its just another option you can toggle, while my impression is that it's incompatible with common Java libraries and requires swapping / maintaining a parallel compiler in the build toolchain, configuring separate rules to build it AOT, etc. I don't have actual experience with it though so I could be missing something.
Go has no proper solution to garbage collector ballast, a hack which businesses you've heard of are using in the wild. see <a href="https://blog.twitch.tv/en/2019/04/10/go-memory-ballast-how-i-learnt-to-stop-worrying-and-love-the-heap-26c2462549a2/" rel="nofollow">https://blog.twitch.tv/en/2019/04/10/go-memory-ballast-how-i...</a> and <a href="https://github.com/golang/go/issues/23044" rel="nofollow">https://github.com/golang/go/issues/23044</a>. A golang team member's reasons for not adding a minimum heap size include that it would require more testing each release, and that they might want to have a max heap size hint instead.<p>I posted a comment similar to this one recently, but it seems more relevant here.
For a short lived Java process you can use the no-op garbage collector (ie don't collect). <a href="http://openjdk.java.net/jeps/318" rel="nofollow">http://openjdk.java.net/jeps/318</a>
When I was looking for my first car in early 90s, I knew nothing about cars or brands. One thing I noticed was that all the TV ads for most of the cars would say "more room than a Camry". I knew what I needed to buy.<p>If Go doesn't survive another decade, I would still be happy about what it triggered.
100 ms is nowhere near what I'd call "negligible" for a process that might only live a second or two!<p>python -c print 'hello' starts up and shuts down an entire Python interpreter in less than 50 ms on my machine, whereas the equivalent Java program never takes less than 120 ms. That seems pretty sad for a language that's had at least an order of magnitude more resources thrown at it.
I've run small services built with Java, Go and Crystal to achieve good startup and throughput performance while minimizing memory usage. My experience with Crystal is limited but has been positive thus far.<p>The sweet spot for me is using Java with OpenJ9 which has very fast startup time while sacrificing only a bit of top-end throughput.<p>I would only choose AOT if packaging/deployment were issues with the JIT approach. In the case of Go, AOT is practically free but I prefer not being limited to array/slice, map, and channel generics.
I'd kill for a comparison with the IBM J9 AOT flag. It essentially just caches jitted code for startup. Also if startup time is super important than you can try -Xquickstart.
Interesting numbers. I have been out of the Java world for a few years and I’m unfamiliar with GraalVM but I’m curious how compatible it is with Oracle Java or OpenJDK.<p>Of course for small scale stuff like a QuickSort implementation, JVM starts are fast-ish, but for a nontrivial service, library load times during boot can balloon quickly depending on your build discipline.
This article reiterates the belief that jvm start-up time is slow is somewhat a myth. When. I measured it years ago, I found jvm start-up time to be roughly equivalent to node.js.<p>What makes start-up time bad in any interpreted language, including Java, python, and JavaScript, is code-loading time. This time is 0(n), where n is the total size of your app, including transitive dependencies. It takes time to load, parse, and validate non-native code. This time far dwarfs any vm start-up time.<p>As an experiment, write a hello world node.js app and time it's execution. Then add an import statement on the aws sdk. Don't actually use it. Just import it! When I last measured it, this caused start-up time to go from 30 Ms to something like 300 Ms. The extra time mostly comes from loading code.<p>For a native app, the binary itself just gets mmapped into memory. Shared library loading is more expensive, but not much, and way less than loading source code or byte code.<p>The tldr is if you want a fast starting non-native app, you have to shrink the transitive dependency closure your app loads to do it's job. This is easy for toy benchmark apps but can be harder for real apps. It also goes against the philosophy of most devs to rely on third party libraries for everything. For instance, If you care about start-up time, it may be worth re implementing that function you'd normally get from guava or apache commons. You can alternatively use a tool like proguard to shrink your dependency closure.
It would be nice to have some automated tools to convert from Java to Go or Rust. Something like c2rust [1], but for Java. There exist[2] some kind of automation, buts it's too basic to be practical.<p>[1] <a href="https://GitHub.com/immunant/c2rust" rel="nofollow">https://GitHub.com/immunant/c2rust</a><p>[2] <a href="https://github.com/aschoerk/converter-page" rel="nofollow">https://github.com/aschoerk/converter-page</a>
Why can't the JVM preload on startup the majority of the core runtime as a shared library architecture in a sort of super-permanent generation, and then the JVMs piggyback on that?<p>I remember solaris boxes had little of the startup cost and someone told me they preloaded the java runtime.
Wouldn't the JIT:ed code be optimized for the specific CPU, whereas the AOT perhaps can not make use of certain instructions? Also, when making a comparison off the different models one must keep in mind that the software that processes the code have different characteristics.
Interesting write-up - would be nice to see not just the quicksort code, but the harness/scripts used for benchmarking. As far as I can tell it's not included?
I wonder if AOT would speed up Groovy as well. My intuition is that it doesn't matter, since the runtime will get bundled and execution time will be the same.
Since the article is about "short lived processes", I'm having a hard time caring about the memory use as a first order issue. <shrug>
For anyone looking to avoid attacks because of no SSL: <a href="https://archive.is/Rzdko" rel="nofollow">https://archive.is/Rzdko</a>