Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JVM Options Explorer

chriswhocodes.com

Post reply on HN
Print view View original

41–50 of 122 posts

Re: JVM Options Explorer

#41

Post by well_ackshually »

Geezus_42 wrote: post #17
Hendrikto wrote: post #2

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.

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.

So your issue isn't with Java, just with shit error messages and devs clearing the exception stack.

Re: JVM Options Explorer

#43

Post by well_ackshually »

rvz wrote: post #23

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…

That's a nice source, from where up your ass did you find it ?

Go's GC is absolutely awful and leads to nondeterministic pauses and catastrophic latency spikes, especially when the memory pressure and capacity is high. Throw the go GC against a 256GB heap, see how well it survives.

Technologies have strong and weak points. Go's strong points are small, targeted pieces of software and having 66% of a binary basically be if err != nil return err. Rust's strong points are that you get to have the symbol> while not saying you're writing c++ and feeling really smug when you say that you only needed to use 5 Arc> and rewrote your entire software three times but at least it runs almost as fast as some shitty C that does fgets() in the middle of a hot loop. Java lets you spawn spring boot and instantiate a string through reflection because why not.

I promise you, I can write allocation heavy FizzBuzzEnterpriseFactoryFactories in Rust too.

Re: JVM Options Explorer

#44

Post by well_ackshually »

motoboi wrote: post #42

People say we don’t build cathedrals anymore. But here it is: JVM is a modern cathedral.

Multiple generations of builders working together on a grand plan, constantly interrupted by multiple generations of ~~kings~~ multibillion dollar corporations to please add ~~a grand mural remembering his great deeds~~ yet another flag to control exactly the timing of GC pauses because it turns out our server can only do GC between 3 and 3:30 AM.

Re: JVM Options Explorer

#45

Post by pjmlp »

Hendrikto wrote: post #2

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?

Re: JVM Options Explorer

#46

Post by vips7L »

TacticalCoder wrote: post #38
Hendrikto wrote: post #2

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…

I could be missing it because I’m not that familiar with bb, but looking at your repository it doesn’t look like you’re using any feature that was actually shipped with project Leyden. It looks like you’re just using AppCDS which has been around for a long time.

Re: JVM Options Explorer

#47

Post by vips7L »

jmyeet wrote: post #39
Hendrikto wrote: post #2

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.

Wasn't it Joel Spolsky who said every option is a cop out? Or maybe Steve Yegge? I forget. It's something I agree with. I often have this thought when going through the options of something conceptually fairly simple: "who is this for? who actually uses this option?" I kinda feel the same way with C/C++ warnings. Different code bases decide if different warnings are errors. That was a mistake (IMHO). The other though…

The GC is pluggable, that’s why you have so many to choose from depending on your work load. You rarely if ever have to touch those options. In the last 10 years all of my apps, since I run on a modern version of Java, only ever set max heap size and soon that will (finally) be figured out automatically: https://openjdk.org/jeps/8359211

Re: JVM Options Explorer

#48

Post by layer8 »

Hendrikto wrote: post #2

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.

The comparison with gofmt makes no sense. If Go had myriads of compiler implementations (the analogy being target environments for the JVM) that all had different performance characteristics and other behavioral differences depending on how the source code is formatted, you bet that gofmt would have a lot of options as well.

The JVM is like an operating system. A better comparison would be Linux kernel parameters: https://www.kernel.org/doc/html/latest/admin-guide/kernel-pa...

Re: JVM Options Explorer

#49

Post by izacus »

jmyeet wrote: post #39
Hendrikto wrote: post #2

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.

Wasn't it Joel Spolsky who said every option is a cop out? Or maybe Steve Yegge? I forget. It's something I agree with. I often have this thought when going through the options of something conceptually fairly simple: "who is this for? who actually uses this option?" I kinda feel the same way with C/C++ warnings. Different code bases decide if different warnings are errors. That was a mistake (IMHO). The other though…

Joe Spolsky also never created anything as popular and widely deployed as Java. It's easy to bloviate about pure software when it doesn't need to literally run the whole world as you know it.

Re: JVM Options Explorer

#50

Post by contraposit »

fHr wrote: post #37
rvz wrote: post #23

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.

I hope AI will make automated translation of such legacy codebases into any favourite langauge possible in future. Fingers crossed.
Post reply on HN