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

71–80 of 122 posts

Re: JVM Options Explorer

#71

Post by vips7L »

cyberpunk wrote: post #55
marginalia_nu wrote: post #22

Earlier quoted context omitted.

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…

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.

Afaik this was fixed a long time ago.

Re: JVM Options Explorer

#72

Post by deepsun »

exabrial wrote: post #51

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/exabri…

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.

Re: JVM Options Explorer

#73

Post by exabrial »

deepsun wrote: post #72
exabrial wrote: post #51

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/exabri…

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.

Re: JVM Options Explorer

#74

Post by eru »

pixl97 wrote: post #15
eru wrote: post #12

Earlier quoted context omitted.

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

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

Re: JVM Options Explorer

#75

Post by EdwardDiego »

cyberpunk wrote: post #55
marginalia_nu wrote: post #22

Earlier quoted context omitted.

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…

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.

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.

Re: JVM Options Explorer

#76

Post by jim33442 »

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.

Re: JVM Options Explorer

#77

Post by cogman10 »

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

Re: JVM Options Explorer

#78

Post by cogman10 »

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.

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

Re: JVM Options Explorer

#80

Post by ecshafer »

mzi wrote: post #5
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.

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

eEjJMOPVWyY

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

Post reply on HN