Stack Overflow Crash
Many Java Virtual Machine publishers reduced the default size of a thread's call stack from 1MB to 256KB. This allows more threads to run simultaneously, but it means that each thread is more limited in how deeply its function calls can be nested.
There are circumstances when a stack overflow crash occurs, as the JRockit JVM cannot handle a stack overflow error gracefully. According to the J2SE Java doc, a gracefully handled java.lang.StackOverflowError is a java.lang.VirtualMachineError thrown to indicate that the JVM is broken or has run out of resources necessary for it to continue operating.
The JRockit JVM .dump file includes information about the number of stack overflow errors thrown.
When the JRockit JVM crashes due to stack overflow, the text crash file (.dump) shows Error Message: Stack overflow near the top of the file. Other indications might be an extremely long stack trace in the crash file or no stack trace at all. If the .dump file shows something like StackOverFlow: 2 StackOverFlowErrors occurred, this is an indication that the crash might be triggered by a previous stack overflow problem.
Often, a stack overflow error is caused by the application being coded to require stack space that exceeds the memory limits of the JRockit JVM. Examine the stack trace in the .dump file to determine whether the Java code can be changed to use less stack space. For example, the application code might contain recursive method calls. Deep recursions can cause StackOverflow errors.
If it is not possible to change the stack requirements of the application, you can change the thread stack size by using the -Xss command-line option.
The -XX:+CheckStacks command-line option makes the JRockit JVM more robust against stack overflow errors. It usually prevents the JVM from dumping and throwing a java.lang.StackOverflowError.
Note: That the -XX:+CheckStacks command-line option results in a slight performance penalty because the JVM touches pages on the stack.
Example: Journal entry report- due to high volume of data got out of memory exception. You reviewed Large XML/BI Reports taking long time to process or fail. Amount of data has changed drastically & issue occurs every time report is executed. Error is thrown when a stack overflow occurs because an application recourses too deeply. The stack size for the BI Manager JVM is not large enough to handle the size of the report data. The reason for this is that the stack size is configured too small. If the stack space is too small for a process to execute, eventually you will see an exception class java.lang.StackOverflowError.
Detail Error shows as below:
BIPDelivery: ERROR:ESS-07033 Job logic indicated a system error occurred while executing an asynchronous java job for request 382583. Job error is: BIP job failed with output error.
Java Virtual Machine (BI Publishers) had the default size of a thread's call stack from 1MB. Raise the Stack Size limit (1MB --> 4MB), to allows more threads (each thread to allow deeper recursion calls) to run simultaneously, accommodate larger XML data.
fusion.BIDomain.bi_cluster.default.minmaxmemory.main=-Xms8192m -Xmx16384m -Xss4096k
fusion.BIDomain.obi.default.minmaxmemory.main=-Xms8192m -Xmx16384m -Xss4096k
Parameter: -Xssn represents Stack Size;
Each Java thread has two stacks: one for Java code and one for C code. This option sets the maximum stack size that can be used by C code in a thread to n. Every thread that is spawned during the execution of the program passed to java has n as its C stack size. The default units for n are bytes and n must be > 1000 bytes. To modify the meaning of n, append either the letter k for kilobytes or the letter m for megabytes. The default stack size is determined by the Linux operating system upon which the Java platform is running.