Refreshing our memory by managing memory in Java... Let's have a quick review on this.
1. Java Heap Size
The place where objects get stored created by our Java application. It's where Garbage Collection takes place. For a heavy Java process, insufficient Heap size will cause the popular
java.lang.OutOfMemoryError: Java heap space.
-Xms<size> - Set initial Java heap size -Xmx<size> - Set maximum Java heap size $ java -Xms512m -Xmx1024m JavaApp
2 . Perm Gen Size
The place where we store our loaded class definition and metadata. If a large code-base project is loaded, the insufficient Perm Gen size will cause the popular
-XX:PermSize<size> - Set initial PermGen Size. -XX:MaxPermSize<size> - Set the maximum PermGen Size. $ java -XX:PermSize=64m -XX:MaxPermSize=128m JavaApp
3. Java Stack Size
It's the size of a Java thread. If a project has a lot of threads processing, try to reduce this stack size to avoid running out of memory. -Xss = set java thread stack size
$ java -Xss512k JavaApp
#2 - PermGen size - not just the initial load, but multiple reloads of the same code can also cause JVM to run out of PermGen space. For some reason, the JVM doesn't reuse PermGen when it reloads code. I've often encountered running out of PermGen space in Tomcat. In a dev env, I usually have the auto-reload on changes set to ON. As I change code and compile multiple times, the JVM+Tomcat reloads my code. After about a day's work, I hit the PermGen out of memory error. When I hit this error, I have to restart Tomcat.
But on production, I've never hit this error, since auto re-loading is switched off. We usually restart tomcat whenever new code is deployed.
#3 - You need to be careful while reducing Xss value. If your call stack is deep, you may hit a Stack Overflow error if Xss is too small. 512k (the default) seems quite OK to me. Even with 100 threads, it will take only 50 Mb.
If a project has more threads than this, well, I'd take a real hard look at why you have so many threads on a single machine. If it's a powerful machine, say with 64 cores which can really handle that many threads due to simultaneous user requests, I'd expect it to have lots more memory as well, like 64G or 128G. Then, even with 1000 threads, the stack memory is still just half-a-gig, a very small percentage of the total server memory.