I've been staring down compiler flags for two weeks straight, now, since I've been working on cross-compilation toolchains, but that kind of narrative doesn't fit your current level of snark, I guess.

I have run operations for programs written in Java, C++, and Go. I've done it both at small companies and large companies, for everywhere from a rack of dedicated servers running Apache Tomcat to thousands of virtual machines running a mixture of C++ and Go microservices.

The constant thread is... over the last ten years... the people running JVMs complain about tuning the JVM, and always have stories to tell about it. The JVM is fantastically tuneable, and when people online complain about GC pauses or memory problems, there's often some way to tune the JVM to fix those problems. The JVM is amazing, it's a marvelous piece of technology.

But there's also a bunch of people who don't know how to do it and just turn knobs. Like, oh, customers are calling in to complain about latency, so I'll increase the size of the Java heap. (Which, for those not familiar with GC, will make throughput better but make latency worse.) Running services on the JVM means that "working with the JVM" is now a skill you need to select for whatever operations team you have, and if you're a company running a mix of different services (like, I don't know, some databases, memcache, load balancers, etc) then "knowing how to tune the JVM" competes with several other skills you'd like your team to learn.

I wrote Java for last ten years and never had to tune anything but Xmx. It just works for me.

In that time, how often did you care about sub millisecond latency SLAs?

(You can read a disk 10 times in series or 100-1000 times in parallel in 1ms; it’s practically an eternity.)

Never. I don't think I would use Java (or any language with GC) for such kind of job, it's more suited for C/C++/Rust.

Depends,

https://www.ptc.com/en/blogs/plm/ptc-perc-virtual-machine-te...

Then, you might be interested in watching this: https://www.youtube.com/watch?v=Pz-4co8IaI8

Just like there are whole conference talks on how to use PGO data properly and optimization flags on AOT compilation toolchains, naturally one needs to spend the effort to learn how to use them and not just type -O2 and go home.

Or those that complain about RDBMS queries being slow, without having normalized their data or written proper indexes.

There is always bunch of people that don't know how to do things, and then there are those among them, that care to improve their skill set and get to know how to turn those knobs.

Sure, but it’s only at large scale that you care about stuff like PGO. My experience is that even small shops care about JVM tuning.

It’s not a question of whether there are knobs to turn. It’s about the typical experience of an actual person running a JVM app versus, say, C or Go, and those experiences are quite different.

And we’re also talking about running someone else’s app. If your database queries are slow, that’s a conversation between the DBA and the devs. If you’re running some Apache app, you’re probably not talking to the devs.

In 20 years of using Java I only had one project where fine-tuning knobs was actually relevant.

Most of the time defaults just work.

Yeah, I've been a C/C++ programmer for 15+ years with heavy focus on performance, and have not once run PGO. I think it's quite often the case for C/C++ programs that you -O2 and walk away, at least for codebases that your team doesn't specifically own.

> My experience is that even small shops care about JVM tuning.

This hasn't been my experience at all after running java on production servers for over a decade.

Unlike C/C++ you do have to care about tuning at a minimum to set the memory sizes.

That said you probably can’t get very far in c/c++ without worrying about memory the whole way through. So, you only worry about tuning when writing your code.

When you run into that problem with Go you stop dead because there is nothing to do.

But that's all compile-time. Someone else very smart can do that and give me an optimized binary. JVM tuning needs to be performed by the end user.

Just like AOT compilation with PGO data.

Well, it's a trade-off. If someone compiled the C++ app for your architecture, sure – if not, you need to figure out how to compile it and depending on the compiler and set of headers you have installed, it's not always easy. When I say, not always easy I'm being generous, there have been cases when the function signature was different between the sets of headers the author had and what I had...

In Java's case if you have all the class files, all you need is the JVM for your architecture. You don't need the program's author to compile it for your architecture.

And finally, JVM tuning does not need to be performed by the user, but can be performed by the user. The most frequent tuning needed to be done by the user was the maximum memory that the JVM could allocate, but that hasn't been needed for a long time (since Java 8, I think). Now the JVM, by default, has the sensible behavior to allocate as much memory as the OS will let it, when asked by the application.

But you can use 99% of C/C++ applications without any compiler flag trickery.

My experience is not that you can run 99% of Java applications without running out of memory or something like that. That's why I avoid Java these days when I have the option. I don't think things would have changed much that much in recent years, making my experience no longer valid.

???

I've been using Java daily for years at this point. The only time I've had that sort of issue is when the program I was writing dealt with large files in memory, and it was solved with a simple -Xmx16G.

Hah, I still use laptops with 2G and 4G :) They work perfectly fine when you know what you are doing. But running Java with 16GB pool does not fall in that category. The same holds for small cloud instances.

Admittedly even with a C program the size of a problem requiring 16GB might not run well in a 2GB machine, but the fact remains that Java applications are often much more memory hungry than comparable C/C++ implementations. And if you have the memory they will just use it without any Xmx. That sounds really like computing in the 1960/70s that you need to allocate memory in advance. (I'm old enough to have seen such stuff, although not when it was new.)

Java may be more memory hungry, but 4gb of memory hasn't been enough for a wide array of tasks for about a decade now.

If your experience was with Java 8, then things have changed radically since then.

9 might have been the last one I have used. I definitely have used 8. (And certainly 1.2, 1.3 etc, but those were different times...)

Is there a concept that the search machine would find, which has brought the radical change you mention?

No, just lots of different things.

G1 has had ~700 improvements since JDK 8 and is now very different: https://archive.fosdem.org/2020/schedule/event/g1/

ZGC, the low-latency collector (which gives a ~1-2ms max pause times on heaps of up to 16TB in JDK 16) was introduced in 11 and made production-ready in 15.

In general, the way the GCs work is just very different from 8.

Plus, there have been lots of improvements to CDS and startup time in general due to how the VM loads classes and initialises data (~30 ms to run Hello, World on a cold VM in 15) -- https://cl4es.github.io/2019/11/20/OpenJDK-Startup-Update.ht..., https://twitter.com/cl4es/status/1311335253139771393, https://www.morling.dev/blog/building-class-data-sharing-arc...

And, of course, now everything lies on top of the module system.

Complete replacement of GC algorithms for start, with G1, ZGC and Shenodah.

Regarding OpenJDK, other JVM vendors have improvements of their own.