Chrome has 1496 [0] known options as of today, maybe after a few more pushes they'll catch up to the 1843 of JVM.

An interface like above to sort things would probably be quite helpful as well.

[0] https://peter.sh/experiments/chromium-command-line-switches/

1843 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.

His other project "Byte Me", along with judicious javap usage, has been super useful for me learning JVM bytecode so I could make a machine learning model compiler for the JVM (basically compile your ML models as native code; ONNX, tree ensembles, regressors, classifiers, etc as native JVM classes with no massive runtime needed)

still in the works, but its here for those interested: Petrify: https://github.com/exabrial/petrify

This is going to come very handy for development of CodeBrew, my Java IDE for iPhone/iPad. It runs a full OpenJ9 JVM under the hood, and I had to do a bunch off massaging with the options to get it to run properly. I wish I had known this page sooner!

For anyone intered, here's the app:

https://apps.apple.com/app/apple-store/id6475267297?pt=11914...

People say we don’t build cathedrals anymore.

But here it is: JVM is a modern cathedral.

Those button at the top link to different domains altogether, but present the same page. So it is one page with multiple domains, instead of one domain with multiple pages.

OK, now make them all run at once!

(I know many conflict and there is not a shell buffer long enough to handle all that)

Kidding aside, I actually said "ugh, seriously" when I saw that there were literally thousands of options. Is there a public program with more options?

There is a 2nd edition now of the Optimizing Java book you are referring to on your site.

All 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.