> It’s safe to assume that if there’s any statics there’s a permgen leak.
private static final int INT_PHI = 0x9e3779b9; // this is a useful constant that can be inlined in JIT code output, and not a memory leak.
> 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.
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.
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.
By the way, when using Java 16, not Java 7 like in the article, those parameters aren't needed.
