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

81–90 of 122 posts

Re: JVM Options Explorer

#81

Post by ivolimmen »

cogman10 wrote: post #77
scrame wrote: post #68

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?

Modern JVMs actually have a solution to the shell buffer problem :D You can shove all those options into a file and instruct the JVM to load them up using `@`. java @all-options.txt -jar my.jar

An option you really need to use on Windows as it has a command option size of only 32Kb. Before you ask: yes I ran into it.

Re: JVM Options Explorer

#82

Post by jim33442 »

cogman10 wrote: post #78
jim33442 wrote: post #76

Earlier quoted context omitted.

I still don't get why Java is the only language that needs the heap to be carefully tuned. Like it hogs some memory at start, crashes if you go above a certain amount, and doesn't return memory to the OS when GC'd. Even Python and JS don't have those problems.

> I still don't get why Java is the only language that needs the heap to be carefully tuned. Only tuning you should be doing is setting the heap size and algorithm (Though, size is likely enough). > Like it hogs some memory at start, crashes if you go above a certain amount, and doesn't return memory to the OS when GC'd. Even Python and JS don't have those problems. Unlike Python and I believe most javascript engines…

Thanks, that's a really good explanation. And makes sense, especially since Java objects are all constantly getting allocated/freed on the (virtual) heap rather than stack.

Re: JVM Options Explorer

#83

Post by pjmlp »

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…

We also don't in other ecosystems, Go advocates pretend we do.

C has had indent since 1976, then it is only a matter of having a pre-commit hook, regardless of the programming language.

We don't need some monk telling us how to format code from the gospels, a company wide rulling suffices.

Re: JVM Options Explorer

#84

Post by pjmlp »

jim33442 wrote: post #76
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 still don't get why Java is the only language that needs the heap to be carefully tuned. Like it hogs some memory at start, crashes if you go above a certain amount, and doesn't return memory to the OS when GC'd. Even Python and JS don't have those problems.

They do, but then people either work around them, or rewrite in Rust.

Java has all these knobs, because the ultimate goal is not needed to rewrite, rather fine tuning, just like when you look at the endless command line options for GCC, clang, MSVC,...

It is also a matter of implementation, Android is Java (kind of), and you also don't get push knobs unless you are a developer talking directly to a single device over ADB.

Re: JVM Options Explorer

#85

Post by pjmlp »

metaltyphoon wrote: post #31
deepsun wrote: post #27

Earlier quoted context omitted.

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

I… didn’t think this makes sense :)

Yes it does, that is why most serious games used to be written in Assembly, until BASIC, Pascal, C and C++ compilers got enough language extensions and compiler knobs to not having to do that all the time, and yet some Assembly is still required.

Re: JVM Options Explorer

#86

Post by pjmlp »

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.

You mean like the waste of the compute in Rust compiler when compiling from source all the time, with the lenghty compilation times it has, multipled by every Rust user when starting a new project?

Re: JVM Options Explorer

#87

Post by asteroidburger »

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.

Tell your developers to start logging the exception, not just a hard-coded error message.

Re: JVM Options Explorer

#88

Post by ncruces »

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.

I appreciate the philosophy behind Go as much as anyone, but this comment sounds tone deaf, and indicative of a certain immaturity.

Many of these flags are the equivalent of GODEBUG. GODEBUG does not have 1843 options, but do you know how many it has? Have you ever used GODEBUG? (I'm guessing no, hence, immaturity) And if not, do you think it should just be dropped because you never needed it?

Re: JVM Options Explorer

#89

Post by iamcalledrob »

Geezus_42 wrote: post #35
thunky wrote: post #28

Earlier quoted context omitted.

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

People give Go's error handing a lot of flak, but I personally love the errors that come out of a quality codebase.

Just like your example: single line, to the point and loggable. e.g.

  writing foo.zip: performing http request (bar.com): tls: handshake: expired certificate (1970-01-01)
Exceptions with stack traces are so much more work for the reader. The effort of distilling what's going on is pushed to me at "runtime". Whereas in Go, this effort happens at compile time. The programmer curates the relevant context.

Re: JVM Options Explorer

#90

Post by gf000 »

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.

Did you mistype Go?

Java has proper error messages with a full stack trace that tells the whole story.

Of course individual developers may lazy out on writing useful error messages, but that's hardly a Java issue.

Meanwhile in Go you can be happy to have any error message at all. And then you can hope it's a unique string you can grep in a codebase. Where you only may find a line of code you could have arrived from many different places.

Post reply on HN