Un proceso de Java consta básicamente de dos espacios de almacenamiento dinámico diferentes.
- El montón de Java (espacio nuevo, antiguo y permanente)
- Y el llamado montón C nativo.
Lo anterior a menudo es confuso cuando se trata de errores de OutOfMemory y fallas de asignación. En particular, en el modo de 32 bits, donde el espacio de proceso general está limitado a 4 GB o incluso a 2 GB, según el sistema operativo.
Como se mencionó anteriormente, el tamaño total del proceso en el modo de 32 bits está limitado a un máximo de 4 gb. Montón de Java y montón de C combinados, junto con otros espacios, p. para bibliotecas, subprocesos, etc. no puede superar este límite de 4 gb. Entonces, si aumenta el montón de Java, p. al aumentar -Xmx/-Xms de 1,5 gb a 2,5 gb, esto tendrá un efecto secundario significativo en el C-heap. Antes del aumento, el C-heap podría crecer fácilmente hasta 2 gb. Ya que quedaban 4gb -1.5gb =2.5gb. DESPUÉS del aumento del montón de Java de 1,5 gb a 2,5 gb, solo nos quedan 4 gb – 2,5 gb =1,5 gb para todos los demás espacios. Incluyendo el montón C.
Desafortunadamente, depende completamente de la aplicación qué tan grande deben ser el montón de Java y el montón de C. Si bien el tamaño del montón de Java se puede configurar explícitamente, esto no se puede hacer para el montón C. C-heap simplemente se expande hasta que el tamaño del proceso alcanza el límite de 4 gb. Por lo tanto, se debe tener cuidado si configura el almacenamiento dinámico de Java demasiado grande. Esto puede y dará como resultado errores de asignación del C-heap. P.ej. los mensajes como este generalmente significan que el C-heap se agotó:
java.lang.OutOfMemoryError: requested 67108872 bytes for Chunk::new. Out of swap space?
Tenga en cuenta la sintaxis de C++ con los dos puntos dobles. O este:
# There is insufficient memory for the Java Runtime Environment to continue. # Native memory allocation (malloc) failed to allocate 65544 bytes
En ambos casos, el montón C era demasiado pequeño. Una solución habría sido disminuir el montón de Java. ¡Sí, para disminuir! Esto le habría dado al C-heap más espacio para expandirse. Por otro lado, aún podemos acceder al clásico Java.lang.OutOfMemoryErrors. Estos apuntan claramente hacia una capacidad de almacenamiento dinámico de Java insuficiente.
Como puede ver, si opera en modo de 32 bits, puede haber un conflicto entre Java y C-heap, que podría no ser fácil de resolver. Si todo falla, considere cambiar a 64 bits, donde el límite de tamaño de proceso de 4 gb ya no será un problema. Información básica:la propia máquina virtual Java (JVM) de Hotspot está escrita en C++. Por lo tanto, todas las asignaciones internas de JVM tienen lugar únicamente en el C-heap. Por ejemplo, cuando el GC se activa para recopilar objetos inactivos en el montón de Java, asignará espacio en el montón nativo para realizar su trabajo.
Por otro lado, todos los objetos de Java que están siendo asignados por un programa de Java terminarán en el montón de Java. El montón C no se tocará.