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

31–40 of 122 posts

Re: JVM Options Explorer

#31

Post by metaltyphoon »

deepsun wrote: post #27
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…

All of that tooling and Rust will always be less efficient than Assembler.

I… didn’t think this makes sense :)

Re: JVM Options Explorer

#32

Post by kitd »

deepsun wrote: post #25
Geezus_42 wrote: post #17

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

This is the kind of scenario that is served better by Go/C-style error values than exceptions. Error values facilitate and encourage you to log what you were doing at the precise point when an error occurs. Doing the same with exceptions idiomatically often requires an exception hierarchy or copious amounts of separate try/catches.

The difference really becomes apparent when trying to debug a customer's problem at 3am (IME).

Re: JVM Options Explorer

#33

Post by appplication »

thunky wrote: post #28
deepsun wrote: post #25

Earlier quoted context omitted.

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.

This is why stack traces exist. But I agree Java seems to not really have a culture of “make the error message helpful”, but instead preferring “make the error message minimal and factual”.

For what it’s worth, the rise of helpful error messages seems to be a relatively new phenomenon the last few years.

Re: JVM Options Explorer

#34

Post by parsd »

avianlyric wrote: post #11
elric wrote: post #8

Earlier 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…

I don’t believe the Go compiler would reject unformatted code. The compiler has its own set of rules for what it views as syntactically correct code, but these rules have nothing to do with gofmt’s formatting rules.

For example, it’s the compiler and not gofmt that dictates that you must write a curly brace only on the same line of an “if” statement. If you put it on the next line, you don’t have unformatted code - you have a syntax error.

However, the compiler doesn’t care if you have too much whitespace between tokens or if you write your slice like []int{1, 2,3,4}, but gofmt does.

We could say the rules of the compiler and gofmt don’t even overlap.

Re: JVM Options Explorer

#35

Post by Geezus_42 »

thunky wrote: post #28
deepsun wrote: post #25

Earlier quoted context omitted.

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.

Sounds to me that deepsun and I are in agreement that an error message should tell you what the actual error was.

I.E. ERROR: TLS handshake failed: certificate chain unverified

Re: JVM Options Explorer

#36

Post by fHr »

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.

Thank god you have no say in where modern tooling is heading, at the creator of the site, absolute right choice to leave it up to the user to chose all options.

Re: JVM Options Explorer

#37

Post by fHr »

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.

Re: JVM Options Explorer

#38

Post by TacticalCoder »

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 (!) and the procedure had to be adapted. I did it all (as a Dockerfile) in less than an hour with Sonnet 4.6 (complete with downloading/verifying the Leyden JVM, testing, taking notes about the project, testing on different machines, etc.).

These are not trivial calls to the "java" command: it involves a specific JVM and several JVM params that have to work fine together.

The goal was to load 80 000 Clojure/java classes (not my idea: the original project did that part) and see the results: 1.5 seconds to launch with the Leyden JVM (and correct params) vs 6 seconds for a regular launch (so a 75% gain). GraalVM is even faster but much more complicated/annoying to get right.

It can look overwhelming but I'd say all these parameters are there for a reason and you only need a few of them. But when you need them, you need them.

P.S: unrelated to TFA and as a bonus for the "Java is slow crowd":

    time java -jar hello/hello.jar
    Hello, World!

    real    0m0.040s
And that's without any Leyden/GraalVM trick. For Clojure the "slow" startup times are due to each Clojure function being transformed into one Java .class each and there are many Clojure functions. Hence the test with 80 000 Clojure functions from the project I reused: https://github.com/jarppe/clojure-app-startup-time-test (but it's not maintained, won't work as if with the latest Leyden JVM)

Re: JVM Options Explorer

#39

Post by jmyeet »

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 thought I have scanning these options is how many are related to GC. I kinda think GC is a bit of a false economy. It's just hiding the complexity. I wonder if it would've been better to push GC to be pluggable rather than relying on a host of options, a bit like TCP congestion management. I mean there are /proc parameters for that in Linux, for example, but it's also segregated (eg using BRR).

At the end of the day, none of this really matters. As in, the JVM is mature and I think generally respected.

Re: JVM Options Explorer

#40

Post by arein3 »

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…

Yeah doubt that

Recently I had a python friend use the most balls to the wall python backend, he couldnt beleive java was faster, but the numbers werent lying. We did 1 billion iterations of adding a float, took a few seconds in java.

Post reply on HN