There is a 2nd edition now of the Optimizing Java book you are referring to on your site.
He probably knows, since he is one of the authors.
JVM Options Explorer
21–30 of 122 posts
Re: JVM Options Explorer
#22Earlier quoted context omitted.
Which JVM options do you use the most?
Heap size, GC algorithm. I suggest most people never touch almost any other options. (Flight recording and heap dumps being the exception).
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
Re: JVM Options Explorer
#23All of that configuration and it will always be less efficient than Rust, or even Golang.
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.
Re: JVM Options Explorer
#24Earlier quoted context omitted.
> You could never even consider all of the possible combinations and interactions, let alone test them. Nobody has ever tested all possible inputs to 64 bit multiplication either. You can sample from the space.
Eh that sounds a bit different to me, multiplication should be roughly the same operator on each test, these are wildly different functions.
You forgot about NaNs (all of them), infinities and positive/negative zeros. Tests warranted.
Re: JVM Options Explorer
#251843 options is too many. You could never even consider all of the possible combinations and interactions, let alone test them. I have really come to appreciate modern opinionated tooling like gofmt, that does not come with hundreds to thousands of knobs.
As a sysadmin, not developer, I hate Java almost as much as Windows. The error messages Java apps produce are like coded messages that you have to decipher. I.E. Instead of " 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.
I hate when tools only produce generic "TLS Handshake failed" instead of saying why exactly it failed, where is the problem.
Re: JVM Options Explorer
#26All of that configuration and it will always be less efficient than Rust, or even Golang. 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 expens…
Sure, for a very narrow definition of _efficiency_. There's plenty to complain in terms of the JVM and Java but performance, as in units of work per dollar spent, is not one of them - JITs just have too many opportunities for optimizing generated code.
Re: JVM Options Explorer
#27All of that configuration and it will always be less efficient than Rust, or even Golang. 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 expens…
All of that tooling and Rust will always be less efficient than Assembler.
Re: JVM Options Explorer
#28Earlier quoted context omitted.
As a sysadmin, not developer, I hate Java almost as much as Windows. The error messages Java apps produce are like coded messages that you have to decipher. I.E. Instead of " 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.
I hate when tools only produce generic "TLS Handshake failed" instead of saying why exactly it failed, where is the problem.
Sounds like you'd both be happy if the tool produced both.
Re: JVM Options Explorer
#291843 options is too many. You could never even consider all of the possible combinations and interactions, let alone test them. I have really come to appreciate modern opinionated tooling like gofmt, that does not come with hundreds to thousands of knobs.
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/fun…
> 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.
Re: JVM Options Explorer
#30Earlier quoted context omitted.
In what way is gofmt remotely comparable to a JVM? 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.
gofmt isn’t really comparable to the JVM, but it is a really strong expression of the opinionated tooling GoLang has. 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 format…
That's all well and good, but entirely irrelevant to the number of options a JVM should reasonably have.