JVM Options Explorer | Hacker News Reader

JVM Options Explorer

chriswhocodes.com

222 points0x54MUR41120 comments

Open articleView on HN

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/

Why not compiling it to Java source code (not bytecode)? Users would use their own Java compiler then.

Same as, say, ANTLR generates code to parse various texts to AST.

the link throws an error 500, "There has been a critical error on this website.":

archived on 2026-04-12: https://web.archive.org/web/20260412085953/https://peter.sh/...

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.

How is this different to system tuning parameters in Linux /proc, FreeBsd, Windows Registry, Firefox about:config, sockopt, ioctl, postgres?

Zillions of options. Some important, some not

One of my nerd-quizzes I hade at interviews before was "what letters in what case are NOT flags to GNU ls".

The answer is 'man ls'. And: 'almost all letters of unicode'.

eEjJMOPVWyY

But I would probably just say without looking it up "man ls", and I basically just use -lta, sometiemes r.

Just because you have more features and ways to use them. Say I like to use a different garbage collector for a tool.

I don't think modernity is a noteworthy factor as to whether tooling is opinionated.

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 formatted in any other way.

It’s a rather extreme approach to opinionated tooling. But you can’t argue with the results, nobody writing go on any project ever worries about code formatting.

They do worry, they just can't do anything about it. Like the fact that error handling code takes at least three lines no matter how trivial it is. I'm sure error handling would not be critisized nearly as much if it didn't consume so much vertical space and could fit in one line, which go compiler does allow.

That's all well and good, but entirely irrelevant to the number of options a JVM should reasonably have.

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.

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.

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/funnest one I used was for an old Sun Microsystems Solaris server which ran iPlanet, for a Java EE service.

Since this shared resources with some other back of office systems, it was prone to run out of memory.

Luckily there was a JVM option to handle this!

-XX:OnOutOfMemoryError="<run command>"

It wasn't too important so we just used to trigger it to restart the whole machine, and it would come back to life. Sometimes we used to mess about and get it to send funny IRC messages like "Immah eaten all your bytez I ded now, please reboot me"

Which JVM options do you use the most?

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.virtualThreadScheduler.maxPoolSize
    -Djava.util.concurrent.ForkJoinPool.common.parallelism

In my experience this often both saves memory and improves performance.

You can get into difficulty with kubernetes here, as your jvm will detect all cores on the node but you may have set a resources limit on the pod/whatever, so it’ll assume it can spend more time doing stuff than it actually can, so often times it’s quite necessary to tune some things to prevent excessive switching etc.

Modern JVMs will detect orchestrator-set cgroup limits and size themselves accordingly. If you, for example, set a cpu limit for a pod to “1”, the JVM will size itself as if it was running on a single core machine.

TIL, this is great. Thanks, saved me some yaml :}

Afaik this was fixed a long time ago.

Nah they fixed the JVM to be container aware some versions ago - I do remember dealing with this in early Java 8 days, think Java 10 is when it got fixed, and then it was backported to later releases of Java 8.

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

> So do we really need multiple thousand?

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.

Did you RTFM? It's not difficult to find the few you actually need.

> You could never even consider all of the possible combinations and interactions, let alone test them.

Nobody has ever tested all possible inputs to 64 bit multiplication either. You can sample from the space.

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.

Don't forget the Intel floating-point division bug from the 90s.

https://en.wikipedia.org/wiki/Pentium_FDIV_bug

I was being a bit hyperbolic.

However, sampling really is the way to go when you face a combinatorial explosion. (If you can't prove it correct, that is.)

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 "<DOMAIN> 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.

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.

A stack trace that is >10 pages in less is not what I would call minimal.

And that's why you should have multiple appenders. So in code you write "log.error("...", exception)" once, but logging writes it in parallel to:

   1. STDOUT for quick and easy look, short format.
   2. File as JSON for node-local collectors.
   3. Proper logging storage like VictoriaLogs/Traces for distributed logging.

Each appender has its own format, some print only short messages, others full stacktraces for all causes (and with extra context information like trace id, customer id etc). I really think STDOUT-only logging is trying to squeeze different purposes into one unformatted stream. (And Go writing everything to STDERR was a really strange choice).

https://www.baeldung.com/logback#bd-appenders

Cool. Convince your fellow Java developers to do that and I'll quit complaining about the awful errors every Java app produces.

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: <DOMAIN> 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.

What?

What you write makes zero sense, see my comment here: https://news.ycombinator.com/item?id=47750450

And come on, skipping 5 lines and only reading the two relevant entries is not "much work". It's a feature that even when developers eventually lazied out, you can still find the error, meanwhile you are at the mercy of a dev in go (and due to the repeating noisy error handling, many of the issues will fail to be properly handled - auto bubbling up is the correct default, not swallowing)

Different strokes for different folks.

The Go errors that I encounter in quality codebases tend to be very well decorated and contain the info I need. Much better than the wall of text I get from a stack trace 24 levels deep.

Apples to oranges.

Quality java code bases also have proper error messages. The difference is that a) you get additional info on how you got to a given point which is an obviously huge win, b) even if it's not a quality code base, which let's be honest, the majority, you still have a good deal of information which may be enough to reconstruct the erroneous code path. Unlike "error", or even worse, swallowing an error case.

> reconstruct the erroneous code path

This is only useful to the developers who should be fixing the bug. Us sysadmins need to know the immediate issue to remediate while the client is breathing down our neck. Collect all the stack traces, heap dumps, whatever you want for later review. Just please stop writing them to the main log where we are just trying to identify the immediate issue and have no idea what all the packages those paths point to do. It just creates more text for us to sift through.

grep "caused by"

Here you are.

Don't have to grep my go errors :)

Especially when they forget to properly handle an error case among the litany of if err line noise, and you get erroneous code execution with no record of it!

Why not just make your errors more readable and not have to use an extra tool?

Well, just write more readable error messages?

How do you make this more readable:

ExceptionName: Dev-given message at Class(line number) at Class(line number) caused by AnotherCauseException: Dev-given message at Class(line number)

It's only the dev given message that may or may not be of good quality, the exact same way as it is in go. It's a plus that you can't accidentally ignore error cases, and even if a dev was lazy, you still have a pretty good record for where a given error case could originate from.

Again, I am a sysadmin, not a developer. Telling me line numbers in a files written in a language I don't understand is not helpful. I don't care where the error occurred in the code. I care what the error was so I can hopefully fix it, assuming its external and not a bug in the code.

And Java typically does produce both (see Exception "cause" field). So when an exception stack trace is printed it's actually list of stacktraces, for each "cause". You can skip stacktraces and just concatenate causes' messages (like people often do in Go).

So the full message would be like "Cannot add item X to cart Y: Error connecting to warehouse Z: Error establishing TLS connection to example.com 127.0.1.1: PKIX failed".

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

This couldn't be further from the truth.

There is no ecosystem I would choose over Java when it comes to observability and it's not even close.

Good luck finding your segfault, oom, race condition or just simply lazy logging culture bug with a C/go codebase at 3am.

I will happily see my proper stack trace, heap dump, or connect directly to prod with a debugger with basically no performance penalty.

That is great for you as a developer. As a sysadmin supporting other people's crap, stack traces and heap dumps are useless beyond forwarding them to the vendor.

Your stack trace tells you where in the code the error occurred, but doesn't tell you what it was doing with what data. For that you need to pass context for the error up the chain of calls, adding to it as you go up. Exceptions are not a great way of doing it as you only have the local context, which isn't a great help when you're catching N levels up.

And if you're not catching N levels up but catching at each level, then you are emulating error values but with try/catch blocks.

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

I would believe you, except that it is a problem with every Java app I have supported, and there are people in this very thread defending it.

I do not want a stack trace unless I specifically request it. I am not a Java developer, 10 pages in less showing names of packages I don't even know what they are is not useful. It just muddies the water so that it's much harder to make sense of and spot the relevant line; assuming there is a line that actually states the error. I shouldn't need to know what all those packages are in order to figure out why Confluence crashed again or stopped sending emails.

When you are administrating so many Java applications, you should investigate an hour or ask your favorite AI how to configure the logging library used in your application of interest. They allow you to remove stack traces and lots more.

That would require convincing the entire organization to change SOP and use a non-standard configuration of the vendor software in a high security private cloud.

Then I've never seen anyone write good Java. Either way, same issue.

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

Not my devely. Most of us support stuff written by external vendors, and most of us don't get to choose who that vendor is.

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.

Btw, Go does have runtime exceptions, they just call them Panics and don't have any nice tooling around it. :)

See my other comments about how stack traces are un-ergonomic for sysadmins. I'm sure they are great for developers.

These are all the options that have ever existed, including options that are or were available only in debug builds used during development and diagnostic options. There are still a few hundred non-diagnostic "product" flags at any one time, but most are intentionally undocumented (the list is compiled from the source code [1]) and are similar in spirit to compiler/linker configuration flags (only in Java, compilation and linking are done at runtime) and they're mostly concerned with various resource constants. It is very rare for most of them to ever be set manually, but if there's some unusual environment or condition, they can be helpful.

[1]: https://github.com/openjdk/jdk/blob/master/src/hotspot/share...

In the age of LLMs coupled with open source software, option count is unlimited. I fork FOSS projects and modify them for my own use all the time. Sometimes, with an agent, doing so is even easier than finding the "right" knob.

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.

> 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)

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.

Ah it's not my repository (I don't have any public repo FWIW): it's a repository I stumbled upon and I decided to port it to a more recent version of the Leyden JVM (using proper AOT, not the very old CDS).

I re-used it for I found it's approach to generating 80 000 Clojure classes to then test bare JVM vs Leyden AOT vs full GraalVM startup timing interesting.

That test does not mean anything. I can also spin up a large LLM on my 5090 and say these models are ready for on device deployment now. However that would not be true for most people. You should test a Golang hello world binary as well. I bet it will take less than 40 milliseconds.

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.

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

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.

Er. IIRC, Spolsky was involved in creating VBA for Excel. Which was arguably orders of magnitude more popular (and still more widely deployed and world-supporting) than Java.

In the 90s, as a program manager. And it's a big difference between building an application and a platform (I've done both) when it comes to API design.

Have you ever seen how many GCC has for plain old C?

Yeah, that’s a mistake too, and a big reason for why compiling C projects is such a pain.

Notice how I did not compare to C, but modern alternatives.

Gccgo and tinygo do exist, with enough parameters.

I'll grant you that Go is extremely opinionated; that's its shtick. But it's an old language that started out with a 1970s design as a statement by its creators against modern programming languages. From its langnauge design, through its compiler, to its GC algorithm, it is intentionally retro (Java retired its Go-like GC five years ago because the algorithm was too antiquated). It may suit your taste and I'm not suggesting that it's bad, but modern it is not.

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

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?

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

Why not compiling it to Java source code (not bytecode)? Users would use their own Java compiler then.

Same as, say, ANTLR generates code to parse various texts to AST.

Great question, actually I tried that! m2cgen is a project that does that in fact.

It works fine for simple models, but breaks down for production-sized tree ensembles. The JVM has a hard 64KB method size limit, and javac controls how your deeply nested if/else trees get laid out. m2cgen's own FAQ says to reduce estimators when you hit recursion limits during generation. With direct bytecode emission I control the method structure precisely, I can split across methods exactly where needed and manage the constant pool directly. I also wrote much more efficient bytecode than m2cgen creates as equivalent source.

The source code is also a pretty useless step, sets off all kinds of static analysis alarms in your stack, and also I worry about source code injection (not that can't happen with petrify, it's just a lot harder).

Finally, I'm grateful for the sweat the authors of m2cgen have put in, but the project has gone without updates for 4 years. That doesn't mean it's useless (some mature software never sees updates), but it's not a positive sign either.

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.

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.

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

He probably knows, since he is one of the authors.

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.

Includes numerous JVM implementations, including Azul Systems'.

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.

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.

Sure, for a very narrow definition of _efficiency_. There's plenty to complain in terms of the JVM and Java but performance, as in units of work per dollar spent, is not one of them - JITs just have too many opportunities for optimizing generated code.

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

I… didn’t think this makes sense :)

It makes perfect sense: Rust compilers will never beat a human at scheduling every single opcode perfectly based on the deepest microarchitectural analysis short of decapping the chip and breaking out the ol' electron microscope. Whether it's worthwhile to be that efficient over a whole program, as opposed to a preternaturally tight compute kernel, is definitely questionable.

> scheduling every single opcode perfectly based on the deepest microarchitectural

Is that even possible knowing OOE+ branch execution and many other CPU tricks?

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.

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.

It sounds like you're not into Java. Perhaps consider switching languages to make room for people who are.

I code on both and they are just for different purposes. E.g. I think it's madness to develop desktop apps in Rust.

Development velocity is way greater in Java.

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?

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.

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<():soup<_, |_| of { c++ }>> while not saying you're writing c++ and feeling really smug when you say that you only needed to use 5 Arc<Mutex<T>> 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.

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, the JVM uses moving garbage collectors. That's the primary reason why it hogs memory.

In these ready to return to OS languages, when something is freed or allocated they are literally calling "malloc" and "free" directly. That's why stuff tends to return back to the OS faster.

The JVM doesn't do that. When a GC runs in the JVM, the JVM picks up and moves live data to a new location. That means the JVM needs a minimum amount of free space to operate. The benefit of this is the JVM can allocate really fast, it's just a single pointer bump and a check to ensure there's enough space. It's pretty close to the same performance as the stack is in C++.

And if there's a lot of data that lives for a short period of time, the JVM frees that data very fast as well. There is little accounting that the JVM has to do to free stuff up because it's simply moving the live data.

For even the fastest allocators that python/javascript engines use, this isn't true. They have to keep track of the various allocation locations and the gaps in allocation when something is freed. And a request for allocation needs to ultimately find a location in the heap with enough room.

Java does have a memory issue, though, all objects in java are pretty bulky. This will hopefully be fixed in future versions when "value" types are added.

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.

No problem.

The GC strategy for Java works best when the JVM has a lot of memory to play with. That's a big reason why a lot of companies use it for the backends.

However, Java suffers when you start talking about small heaps. This has become a much bigger issue as containered applications have risen as a primary deployment method. There are active efforts ongoing to solve this problem and make Java more friendly to smaller memory footprints and containers in general.

The Go/python/javascript strategies end up working better in those situations. They have very fast startups and pretty low memory requirements. However, when you start talking about apps that need a lot of memory, they both end up suffering as their allocation strategies degrade as the memory being tracked grows. Especially if there's a large amount of memory churn. The JVM has about the best strategy for very high memory churn.

Yeah the Java way makes sense if it's the only thing running on that machine, or at least you know ahead of time how much RAM to budget to each thing. Which was often the case on servers. I'm not surprised if that performs better than Go in a way, but seems like Go does ok. If they really wanted a custom heap on top of preallocated memory in a Go program, couldn't they just do that?

The weirder part is that Java also used to be a bigger thing client-side, back when websites commonly included Java applets.

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.

You don't have to do anything, it just works.

But eventually someone gonna write the goddamn whole of AWS or Alibaba in the language where you have machines with TBs of heaps (yeah, you read that right), where most other managed languages would just give up instantly - and then you may have to add 2-3 parameters to make it actually run properly in these extreme conditions.

Reply on news.ycombinator.com