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

101–110 of 122 posts

Re: JVM Options Explorer

#101

Post by TacticalCoder »

vips7L wrote: post #46
TacticalCoder wrote: post #38

Earlier quoted context omitted.

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

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.

Re: JVM Options Explorer

#102

Post by cogman10 »

jim33442 wrote: post #82
cogman10 wrote: post #78

Earlier quoted context omitted.

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

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.

Re: JVM Options Explorer

#103

Post by gf000 »

Geezus_42 wrote: post #100
gf000 wrote: post #95

Earlier quoted context omitted.

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…

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

grep "caused by"

Here you are.

Re: JVM Options Explorer

#104

Post by iamcalledrob »

gf000 wrote: post #103
Geezus_42 wrote: post #100

Earlier quoted context omitted.

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

grep "caused by" Here you are.

Don't have to grep my go errors :)

Re: JVM Options Explorer

#106

Post by jim33442 »

cogman10 wrote: post #102
jim33442 wrote: post #82

Earlier quoted context omitted.

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…

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.

Re: JVM Options Explorer

#107

Post by deepsun »

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.

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

Re: JVM Options Explorer

#108

Post by deepsun »

gf000 wrote: post #90
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.

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

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

Re: JVM Options Explorer

#109

Post by Geezus_42 »

gf000 wrote: post #103
Geezus_42 wrote: post #100

Earlier quoted context omitted.

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

grep "caused by" Here you are.

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

Re: JVM Options Explorer

#110

Post by Geezus_42 »

asteroidburger wrote: post #87
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.

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.
Post reply on HN