Symptoms

JIRA crash when it is run as Windows Service. The following appears in the *-stdout.*.log:

2011-11-15 14:29:52 Commons Daemon procrun stdout initialized#
# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (malloc) failed to allocate 131080 bytes for Chunk::new
# An error report file with more information is saved as:
# C:\Windows\system32\hs_err_pid2772.log

The hs_err_pid*.log generated will have the following error: 

#
# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (malloc) failed to allocate 1158664 bytes for Chunk::new
# Possible reasons:
#   The system is out of physical RAM or swap space
#   In 32 bit mode, the process size limit was hit
# Possible solutions:
#   Reduce memory load on the system
#   Increase physical memory or swap space
#   Check if swap backing store is full
#   Use 64 bit Java on a 64 bit OS
#   Decrease Java heap size (-Xmx/-Xms)
#   Decrease number of Java threads
#   Decrease Java thread stack sizes (-Xss)
#   Set larger code cache with -XX:ReservedCodeCacheSize=
# This output file may be truncated or incomplete.
#
#  Out of Memory Error (allocation.cpp:317), pid=1172, tid=3184
#
# JRE version: 6.0_26-b03
# Java VM: Java HotSpot(TM) Server VM (20.1-b02 mixed mode windows-x86 )

Cause

This indicates that the Java Virtual Machine (JVM) has crashed because it is unable to obtain the necessary memory it requires from the operating system. The JVM will start up and attempt to reserve the minimum amount of memory as set in the Xms parameter which is usually 128mb. As JIRA requires more memory, it requests it from the JVM which will request it from the operating system. The available memory to JIRA (the heap size) will continue to expand up to the maximum memory allocation (Xmx). At any point the JVM can destroy objects in that memory using a process called Garbage Collection that will free up the memory. However, this crash typically comes from the JVM requesting memory from the OS and as the OS cannot provide it (as that memory may have been allocated elsewhere), so the JVM crashes, and JIRA is inaccesible.

JIRA can run for some time before this happens, as the heap will slowly expand until it hits a point where it's unable to retrieve that memory and then the process dies. For example, when running JIRA on a 32-bit OS the maximum available memory is only 1400mb. This consists of the maximum memory + PermGen + the JVM overhead (roughly 128mb). This gives a maximum of 1024 heap (Xmx) + 256 PermGen + 128 from the JVM (1408 total) for a JIRA instance. If there are other applications competing for that available memory on the same 32-bit OS it can cause this behaviour.

 Please see this Stackoverflow answer for further information on the memory limitations of Java in a 32-bit OS.

Workaround

1. Set the minimum and the maximum memory to the same amount (1024mb at most) as per Increasing JIRA Memory.
2. Restart JIRA.
3. If the problem persists, lower the minimum and maximum memory to 768mb, as if it's failing at 1024 it indicates the OS cannot provide sufficient memory.

Resolution

Upgrading to a 64-bit OS and the latest 64-bit version of JIRA will provide more available memory to a JVM and will resolve the problem.