Detecting a permgen memory leak in a Java application
smalldata.techUh… PermGen? What year is it? This must be blog spam from the past.
It wouldn't surprise me if many enterprise systems were still reliant on Java 7. Where I work, most of our stacks still depend on Java 8.
2015.
Yes, Permgen disappeared in Java8 I believe.
Long live Metaspace.
Detecting? It's safe to assume that if there's any statics there's a permgen leak.
Mutable collection type static field members that are actually mutated, sure. Thread creation in a static initializer? Yeah, that’s going to be a leak- but what you said was:
> 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.
It might use the word static, but in my head it's just a const, obviously fixed integers don't leak. Why bother pointing this out?
> 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.
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.