Is it possible that setting -Xmx to high on a 32 JVM can shrink the space available to JNI such that JNI fails?

Question

I have a problem where allocating to much -Xmx causes a problem of the most unusual kind.

The Problem: Setting -Xmx to 3072m on a 32bit JVM on a 64bit Linux OS works except for one condition where a servlet attempts to communicate with many outside entities via JNI IPC. When we lower the -Xmx to 2048m it works. No errors within tomcat are ever seen. The only errors that are seen are within the JNI logging code.

This leads me to believe that since this is a 32bit process, setting the max java heap space to 3072m leaves to little space for the JNI C++ native code. It cannot allocate enough space for.. threads, or whatever.

I've investigated: Maximum Java heap size of a 32-bit JVM on a 64-bit OS and this isn't what I'm asking.

The Question:

Is it possible that setting -Xmx to high on a 32 JVM can shrink the space available to JNI such that it fails? How might we determine for a given situation what is available to that JNI process?

The list of Knowns:

Linux 64bit HCOS-130:~ # uname -a Linux HCOS-130 2.6.27.19-5-default #1 SMP 2009-02-28 04:40:21 +0100 x86_64 x86_64 x86_64 GNU/Linux

java 6 32bit jre1.6.0_45

CATALINA_OPTS="-server -Xmx3072m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=$CATALINA_HOME/logs"

ps aux | grep -i jsvc

root     19827  0.0  0.0   2344   368 ?        Ss   17:32   0:00 jsvc.exec -user tomcat -home /usr/java/jre1.6.0_45 -Dcatalina.home=/usr/java/apache-tomcat -Djava.security.auth.login.config=/usr/java/apache-tomcat/conf/jaas.conf -Djavax.net.ssl.trustStore=/usr/java/apache-tomcat/conf/truststore.ks -Djavax.net.ssl.trustStorePassword=changeit -Djava.awt.headless=true -Djava.io.tmpdir=/usr/java/apache-tomcat/temp -Djavax.net.ssl.trustStore=/usr/java/apache-tomcat/conf/truststore.ks -Djavax.net.ssl.trustStorePassword=changeit -outfile /usr/java/apache-tomcat/logs/catalina.out -errfile /usr/java/apache-tomcat/logs/catalina.err -server -Xmx3072m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/usr/java/apache-tomcat/logs -cp /usr/java/apache-tomcat/conf:/usr/java/apache-tomcat/bin/bootstrap.jar:/usr/java/apache-tomcat/bin/commons-daemon.jar:/usr/java/apache-tomcat/bin/tomcat-juli.jar:/usr/java/apache-tomcat/shared/lib/jni.jar:/usr/java/apache-tomcat/shared/lib/log4j-1.2.14.jar:/usr/java/apache-tomcat/shared/lib/dhcajni.jar:/usr/java/apache-tomcat/shared/lib/activejni.jar org.apache.catalina.startup.Bootstrap

tomcat   19829  1.5  0.1 2863864 162164 ?      Sl   17:32   0:10 jsvc.exec -user tomcat -home /usr/java/jre1.6.0_45 -Dcatalina.home=/usr/java/apache-tomcat -Djava.security.auth.login.config=/usr/java/apache-tomcat/conf/jaas.conf -Djavax.net.ssl.trustStore=/usr/java/apache-tomcat/conf/truststore.ks -Djavax.net.ssl.trustStorePassword=changeit -Djava.awt.headless=true -Djava.io.tmpdir=/usr/java/apache-tomcat/temp -Djavax.net.ssl.trustStore=/usr/java/apache-tomcat/conf/truststore.ks -Djavax.net.ssl.trustStorePassword=changeit -outfile /usr/java/apache-tomcat/logs/catalina.out -errfile /usr/java/apache-tomcat/logs/catalina.err -server -Xmx3072m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/usr/java/apache-tomcat/logs -cp /usr/java/apache-tomcat/conf:/usr/java/apache-tomcat/bin/bootstrap.jar:/usr/java/apache-tomcat/bin/commons-daemon.jar:/usr/java/apache-tomcat/bin/tomcat-juli.jar:/usr/java/apache-tomcat/shared/lib/jni.jar:/usr/java/apache-tomcat/shared/lib/log4j-1.2.14.jar:/usr/java/apache-tomcat/shared/lib/dhcajni.jar:/usr/java/apache-tomcat/shared/lib/activejni.jar org.apache.catalina.startup.Bootstrap

Answer 1

Yes.
The larger the memory heap, the smaller the native heap becomes. Mentioned here

The memory space provided by the operating system to the Java process varies by operating system and is used for two separate memory areas: the Java heap and the native heap. Because a finite amount of memory is provided by the operating system, and that memory is shared between the two heaps, the larger the amount of memory that is allocated to the Java heap, using the -Xmx setting, the smaller the native heap becomes. If the native heap is too small, an OutOfMemoryError occurs when it is exhausted, in the same way as for the Java heap.

It applies to Oracle as well.
The fact that you are on a 64-bit OS is irrelevant. You are using a 32-bit JVM and as a result are restricted in memory