For anyone intered, here's the app:
https://apps.apple.com/app/apple-store/id6475267297?pt=11914...
This is why lots of engineers waste time fiddling with options to tune the JVM and still require hundreds of replicated micro-services to "scale" their backends and losing money on AWS and when they will never admit the issue is the technology they have chosen (Java) and why AWS loves their customers using inefficient and expensive technologies.
Even after that, both Go and Rust continue to run rings around the JVM no matter the combination of options.
Hendrikto•1h ago
I have really come to appreciate modern opinionated tooling like gofmt, that does not come with hundreds to thousands of knobs.
tezza•1h ago
Zillions of options. Some important, some not
mzi•1h ago
eru•47m ago
deepsun•1h ago
RadiozRadioz•1h ago
elric•59m ago
In reality the number of options is significantly smaller than the 1843 you mentioned. The list contains boatloads of duplicates because they exist for multiple architectures. E.g. BackgroundCompilation is present on 8 lines on the OpenJDK 25 page: aarch64, arm, ppc, riscv, s390, x86 and twice more without an architecture.
avianlyric•48m ago
While gofmt is “just” a formatting tool. The interesting part is that go code that doesn’t follow the go formatting standard is rejected by the go compiler. So not only does gofmt not have knobs, you can’t even fork it to add knobs, because the rest of the go ecosystem will outright reject code formatted in any other way.
It’s a rather extreme approach to opinionated tooling. But you can’t argue with the results, nobody writing go on any project ever worries about code formatting.
kfuse•13m ago
tomaytotomato•59m ago
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"
nkzd•48m ago
cogman10•43m ago
I suggest most people never touch almost any other options. (Flight recording and heap dumps being the exception).
marginalia_nu•6m ago
Not JVM options, but these are often also good to tune:
In my experience this often both saves memory and improves performance.eru•47m ago
Nobody has ever tested all possible inputs to 64 bit multiplication either. You can sample from the space.
pixl97•42m ago
Geezus_42•30m ago
I.E. Instead of "<DOMAIN> TLS Handshake failed" it will be something like "ERROR: PKIX failed". So now I have to figure out that PKIX is referring to PKI and it would make too much sense to provide the domain that failed. Instead I have to play the guessing game.
pron•20m ago
[1]: https://github.com/openjdk/jdk/blob/master/src/hotspot/share...
quotemstr•15m ago