If there is still free memory in the system when a native out-of-memory error occurs, then the problem is likely to be a shortage of memory in the low-memory region (under 4GB). Although the Java heap can be located above this boundary, other data, which are associated with Java objects, are located in the lower memory segments. Specifically these are the memory segments associated with threads, classes and monitors. 

See the following related content:

• Using -Xgc:preferredHeapBase with -Xcompressedrefs
   
• Thanks for the memory
   

The operating system memory allocator will deal out low memory freely, so memory resources in the lower boundary may run out.  Later when the JVM tries to allocate memory for an artifact, which is required to be allocated in low memory because the JVM has only reserved a 32-bit pointer for it, it fails and throws an out-of-memory error.

Starting in Java 6.0.0 SR16FP3, Java 6.0.1 SR8FP3, Java 7.0.0 SR2FP10, there is a -Xmcrs parameter, which allows the JVM to increase the amount of low memory it reserves on start up. With this setting, as long as the lower memory usage by the JVM does not exceed the -Xmcrs value, native out-of-memory in the lower boundary will be avoided. For more information, see -Xmcrs in the IBM SDK, Java Technology Edition documentation.

To set this parameter, first decide what a reasonable value for your lower memory requirements may be.  Reasonable value is unique to each environment so there is not a general recommendation.

To determine a <reasonable_value_for_lower_memory> value, check the javacore for low memory usage when the native out-of-memory error occurred.  A quick formula would have you look at the "NATIVEMEMINFO subcomponent dump routine" section. Subtract  the "Memory Manager (GC)" value from "VM" value and multiply the result by 1.5. In this case:  (9689267552-8771635584)*1.5=1376447952=1312.68M=<reasonable_value_for_lower_memory>.  However, because we generally reserve memory in 256MB denominations, round up to 1536M....-Xmcrs1536M

From Javacore at time of the native out-of-memory error:

NATIVEMEMINFO subcomponent dump routine
=================================

JRE: 10,312,883,816 bytes / 146227 allocations  
|
+--VM: 9,689,267,552 bytes / 122234 allocations  
|  |
|  +--Classes: 780,311,496 bytes / 81034 allocations
|  |  |
|  |  +--Shared Class Cache: 62,914,560 bytes / 1 allocation
|  |  |
|  |  +--Other: 717,396,936 bytes / 81033 allocations
|  |
|  +--Memory Manager (GC): 8,771,635,584 bytes / 2858 allocations
|  |  |
|  |  +--Java Heap: 8,589,934,592 bytes / 1 allocation
|  |  |
|  |  +--Other: 181,700,992 bytes / 2857 allocations

...

 

Note: Setting -Xmcrs too high would be a waste of memory that could be used for other purposes. Choose a value based on your specific memory needs as explained above.

 

memory-removable-computer (modified) credit: (cc) Some rights reserved by charlemagne

Tags:  java heap memory