Posted by st10470
on May 23, 2008 at 8:20 AM PDT
Working on an 300,000 lines of code project, we found the non-heap memory size to inflate from about 40 Mbytes to 65 Mbytes during a well identified part of the server lifecycle, that involves database access (Solid 4.5 through JDBC) and network acquisition (java.nio).
We would like to reduce this stack memory footprint, if ever possible.
Failing this, we will need to explain it at least.
What are the most likely root causes of the non heap memory to inflate ?
From the JVM spec 2nd Ed, I found that the method frame is the place in the stack where a lot of memory space may be allocated, for a stack frame is created for each method and contains:
- Local variables allocation
- Method operand stack
And other low memory-consumer areas:
- Reference to the runtime constant pool
- Method result return
The only tracks I found are:
- Look for methods atomicity to reduce local variables lifetime
- Avoid runaway recursive methods
This task looks exhausting and likely with a low benefit. What are your views on this ?
Do you know some other tracks to follow to reduce the stack size in the code, architecture, or by JVM tuning ?
Or on the contrary, could I prove that it is impossible, because this is a JVM private part, which is already optimized ?
We use the J2SE with the JRE 1.5.0_08 under Linux 2.6.18.
The application launches about 200 Threads max but these are static, and reducing the stack size with -Xss does not seem to have any effect.
The JVM spec lets the implementors take this parameter into account or not, it seems it is not the case in the one we use.
Thanks in advance for your answers or comments.