java - outofmemoryerror - ¿Por qué el tamaño predeterminado de PermGen es tan pequeño?

java.lang.outofmemoryerror: permgen space jboss (3)

Conceptualmente, para el programador, se podría argumentar que una "Generación Permanente" es en gran medida inútil. Si necesita cargar una clase u otros datos "permanentes" y queda espacio en la memoria, entonces, en principio, también puede cargarlo en algún lugar y no preocuparse de llamar al conjunto de estos elementos una "generación" en absoluto.

Sin embargo, la razón es probablemente más que:

existe un beneficio potencial (p. ej., desde el punto de vista del caché del procesador) de tener todos los metadatos de código / clase juntos en el espacio de la memoria, y para garantizar esto es más fácil asignar áreas de tamaño fijo;
De manera similar, el espacio de memoria donde se almacenan los metadatos de código / clase tiene potencialmente ciertas propiedades "especiales" (en particular, no desea que se distribuyan en el disco si puede ayudarlo) y es posible que el sistema no pueda configurar dichas propiedades. en la memoria de una manera muy granular, de modo que es más práctico tener todos los objetos "especiales" juntos en un bloque contiguo (o un pequeño número de) o espacio de memoria contiguo;
tener objetos permanentes todos juntos ayuda a evitar la fragmentación del espacio de memoria restante y, una vez más, la forma más práctica de hacerlo es asignar un bloque de memoria contiguo de tamaño fijo desde el principio.

Entonces, como veo las cosas, la mayor parte del tiempo la razón para asignar una "generación" permanente es realmente por razones prácticas de implementación que porque el programador realmente se preocupa muchísimo.

Por otro lado, la situación tampoco suele ser terrible para el programador: la cantidad de generación permanente necesaria suele ser predecible, por lo que debería poder asignar la cantidad requerida con un margen de maniobra decente. Por lo tanto, si descubre que está superando inesperadamente la asignación, esto puede ser una señal de que "algo grave está mal".

NB Es probable que algunos de los problemas que el PermGen originalmente fue diseñado para resolver no sean problemas tan grandes en los procesadores modernos de 64 bits con cachés de procesadores más grandes. Si se elimina en futuras versiones de Java, es probable que esto sea una señal de que los diseñadores de JVM sienten que ahora ha "cumplido su propósito".

¿Cuál sería el propósito de limitar el tamaño del espacio Permgen en una JVM de Java? ¿Por qué no siempre se establece igual al tamaño máximo del montón? ¿Por qué Java utiliza de forma predeterminada un número tan pequeño de 64 MB? ¿Están tratando de obligar a las personas a notar los problemas de permgen en su código al hacer esto?

Si mi aplicación usa 85MB de permgen, entonces podría ser seguro configurarlo a 96MB pero ¿por qué configurarlo tan pequeño si es realmente parte del montón principal? ¿No sería eficiente permitir que la JVM use tanto PermGen como lo permita el montón?

El PermGen está configurado para desaparecer en JDK8.

¿Cuál sería el propósito de limitar el tamaño del espacio Permgen en una JVM de Java?

No agotar los recursos.

¿Por qué no siempre se establece igual al tamaño máximo del montón?

El PermGen no es parte del montón de Java. Además, incluso si lo fuera, no sería de mucha ayuda para la aplicación llenar el montón con metadatos de clase y cadenas constantes, ya que en su lugar aparecerían los errores "OutOfMemoryError: Java Hize size"

PermGen es donde se asignan los datos de clase y otras cosas estáticas (como los literales de cadena).

Preferiría asignar memoria al montón de Java para los datos de su aplicación ( Xms y Xmx , donde van los objetos jóvenes (de corta duración) y permanentes (cuando la JVM se da cuenta de que necesitan quedarse por más tiempo)).

Por lo tanto, el valor predeterminado histórico de PermGen 64MB puede ser arbitrario, pero tenerlo configurado explícitamente le permite saber (y controlar) la cantidad de datos estáticos que su aplicación está causando que la JVM almacene.