51–60 of 122 posts
still in the works, but its here for those interested: Petrify: https://github.com/exabrial/petrify
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.
> 1843 options is too many. You could never even consider all of the possible combinations and interactions, let alone test them. You can search for those that may concern you. Good old search or AI "search". For example I recently did test the AOT compilation of Clojure (on top of the JVM) code using "Leyden". I used an abandoned Github project as a base but all the JVM parameters related to Leyden had changed names…
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 expens…
I was a diehard java fanboy but using Rust in the last 5 years more and more I have to agree, but sadly huge Java corporate codebases keep my bills paid still, so I have to deal with it. It is what it is. Also agree the pipeline etc. they love all the waste of the compute in their pocket.
An interface like above to sort things would probably be quite helpful as well.
[0] https://peter.sh/experiments/chromium-command-line-switches/
Earlier quoted context omitted.
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.virtualThrea…
Earlier quoted context omitted.
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.
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.
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/
Same as, say, ANTLR generates code to parse various texts to AST.
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.
Have you ever seen how many GCC has for plain old C?
Notice how I did not compare to C, but modern alternatives.
Earlier quoted context omitted.
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.