It's a result of Java being required to run on many different OS environments (Oracle, Redhat, Windows, RISC/ARM/x86), along with user constraints and also business requirements.

In a way you can use this list of JVM options to illustrate how successful Java has become, that everyone needs an option to get it to work how they like it.

As a Java dev, I have maybe used about 10-15 of them in my career.

The weirdest/funnest one I used was for an old Sun Microsystems Solaris server which ran iPlanet, for a Java EE service.

Since this shared resources with some other back of office systems, it was prone to run out of memory.

Luckily there was a JVM option to handle this!

-XX:OnOutOfMemoryError="<run command>"

It wasn't too important so we just used to trigger it to restart the whole machine, and it would come back to life. Sometimes we used to mess about and get it to send funny IRC messages like "Immah eaten all your bytez I ded now, please reboot me"

▲ Hendrikto 7 hours ago | parent | next [-]

> As a Java dev, I have maybe used about 10-15 of them in my career.

So do we really need multiple thousand? Having all of them also makes finding the few you actually need much more difficult.

	▲	KronisLV 4 hours ago \| parent [-]
		> So do we really need multiple thousand? Assuming that you don't need 99.9% of them (they should have sane defaults that you never have to change or even learn that they exist or what they are) until that super rare case when one will save your hide, I'd lean towards yes. In other words, they might as well be an escape hatch of sorts, that goes untouched most of the time, but is there for a reason. > Having all of them also makes finding the few you actually need much more difficult. This is a good point! I'd expect the most commonly changed ones (e.g. memory allocation and thread pools) to be decently well documented, on the web and in LLM training data sets. Reading the raw docs will read like noise, however.

▲ nkzd 8 hours ago | parent | prev [-]

Which JVM options do you use the most?

▲ cogman10 8 hours ago | parent [-]

Heap size, GC algorithm.

I suggest most people never touch almost any other options. (Flight recording and heap dumps being the exception).

▲ marginalia_nu 8 hours ago | parent [-]

GC threads are generally often useful on multi-tenant systems or machines with many cores, as Java will default-size its thread pools according to the number of logical cores. If the server has 16 or more cores, that's very rarely something you want, especially if you run multiple JVMs on the same host.

Not JVM options, but these are often also good to tune:

    -Djdk.virtualThreadScheduler.parallelism
    -Djdk.virtualThreadScheduler.maxPoolSize
    -Djava.util.concurrent.ForkJoinPool.common.parallelism

In my experience this often both saves memory and improves performance.

▲

cyberpunk 4 hours ago | parent [-]

You can get into difficulty with kubernetes here, as your jvm will detect all cores on the node but you may have set a resources limit on the pod/whatever, so it’ll assume it can spend more time doing stuff than it actually can, so often times it’s quite necessary to tune some things to prevent excessive switching etc.

	▲	dpratt 2 hours ago \| parent [-]
		Modern JVMs will detect orchestrator-set cgroup limits and size themselves accordingly. If you, for example, set a cpu limit for a pod to “1”, the JVM will size itself as if it was running on a single core machine.