Hacker News new | ask | show | jobs
by theamk 1777 days ago
> Steps to use visualvm to profile memory for a standalone JBoss application:

> Allow visualvm to use 1024 Mb of RAM - in etc/visualvm.conf update -Xmx parameter to -J-Xmx1024m

And this is why I avoid all Java apps I can -- there is always a need for some memory tuning. C++, Lisp, Perl, Go, Python, even Javascript can all use all the memory in my computer have without any action on my part, only Java keeps having the problems with it.

5 comments

You are lucky to work in systems where using all the memory is an option. Our servers have 256GB of RAM and we must constrain the memory of all our java trading robots, and then tune (but if we tune it means we didnt predict correctly) or optimize (which is basically doing what you do in C++ if you re constrained: never malloc to the heap without knowing what you re doing)

As an anecdotal experience tells me here in my investment bank, the algo trading robots in C++ take an order of magnitude more time to get right, change, or fit their constraints than the java validation robots we work on, simply because the memory tooling in Java is really easier to use.

The default limit is usually 25% of total physical memory. Should the default limit be the maximum? I think it's fine to have the default limit where it's at, to force me to think about what the actual requirements are. When you mean "tuning", do you also mean random GC tweaks? Those are generally best avoided these days, in my opinion. The auto tuning works well enough, and manual settings tend to cause more harm than good in the long run.
The problem is: when devs have learned about a necessary tuning knob, it's almost impossible to get them to stop touching it.

So recent JDKs have a sane default. Finally. Now we have a zillion app from the time defaults were not sane, each having a few -Xm parameters in their config. If they work well enough, nobody takes the effort to remove them. If they don't work, just type a higher number and test.

Manual JVM memory tuning will stay with us forever.

No they can't. You're just to inexperienced to know this.
It's nice to have inbuilt memory limits in programs. It's a nice demarcation to have.
I wonder why I had to do memory tuning on C applications back in 2000.

By the way, when using Java 16, not Java 7 like in the article, those parameters aren't needed.