tutorial - Java: ¿Por qué existe MaxPermSize?

text box java (7)

¿Por qué existe MaxPermSize?

Al tener la configuración de MaxPermSize, su aplicación lanzará el error de memoria agotada del GC en el inicio, por lo que no cree que la aplicación esté funcionando y que sus clientes llamen porque el sistema no funciona o es muy lento.

Digamos que tiene 4 GB en su VM y sabe que necesita 2 GB de espacio no permanente para que su aplicación alcance las métricas de rendimiento acordadas contractualmente. Si su generación de perm va a ocupar más de 2 gb, no tiene sentido iniciar la aplicación, ya que no podrá cumplir con las medidas de rendimiento que se enumeran en su declaración de trabajo.

Es mejor saber que en el inicio, y obtener más memoria en la caja, o reconfigurar su VM para tomar más memoria física del servidor (en cualquier caso) que para iniciar la aplicación, permitir las clases, ehcache o lo que sea para cargar, piense que todo está bien y luego descubra a sus clientes que el sistema está demorando 10 segundos en cargar una página.

Aquí hay un buen artículo sobre la generación permanente en el recolector de basura:

Presentando la Generación Permanente en el weblog de Jon Masamitsu

EDITAR:

No he visto nada que indique por qué tomaron la decisión de diseño de tener un límite máximo en el tamaño de generación permanente. Pero me imagino que se hizo por varias razones.

Hace que sea mucho más fácil de implementar, los GC son decididamente no triviales, por lo que simplificar su implementación de cualquier manera es probablemente una buena idea.
YAGNI (No lo va a necesitar) la mayoría de las aplicaciones cargan un número fijo de clases y, por lo general, no son particularmente grandes, por lo que probablemente se han optimizado para el caso común y simplemente eligieron un valor predeterminado sano y lo dejaron configurable.
Suponiendo que el tamaño de la generación permanente está creciendo de forma impredecible, es probable que tenga un error en un cargador de clases (o que tenga que repensar su arquitectura). Incluso en las aplicaciones que generan clases en tiempo de ejecución (o realizan otros trucos similares), el número de clases generadas también suele ser fijo, por lo que debería poder ajustar maxperm para que se ajuste a sus necesidades.
No soy un experto en todos los detalles de la carga de clases Java y la recolección de basura, pero ambos son partes complicadas de la JVM, así que imagino que intentarán mantener estos dos componentes lo más ortogonales posible y permitir que crezca el gen perm. probablemente dinámicamente uniría estos dos componentes de manera complicada (especialmente porque ambos componentes tienen serias consideraciones sobre el enhebrado)
Probablemente haya algunos beneficios de rendimiento al limitar la generación máxima de permisos, ya que permitir que crezca puede implicar una copia adicional de la colección, o puede significar que su generación de permisos ya no existe en un espacio de direcciones contiguo, lo que podría afectar la forma en que otros algoritmos Trabajo para la gestión de la colección.

Obviamente estas son todas especulaciones. Pero incluso si todo esto está mal, definitivamente no creo que sea ''idiota'' que Sun haya elegido un tamaño fijo, probablemente haya muchas más consideraciones de ingeniería e implementación de las que podría haber soñado :)

Existe porque ayuda a ajustar el subsistema de recolección de basura dentro de la JVM. Dependiendo de la arquitectura subyacente y la administración de la memoria, una implementación de JVM puede tener una recolección de basura subóptima (por ejemplo, demasiado flexible) ... Puede especificar un MaxPermSize a mano en lugar de tenerlo calculado para que la aplicación se comporte sin problemas ...

La página de Java GC dice más ...

La generación permanente se utiliza para reflejar la propia máquina virtual, como los objetos de clase y los objetos de método. Estos objetos reflectantes se asignan directamente a la generación permanente, y se dimensionan independientemente de las otras generaciones. En general, el tamaño de esta generación puede ignorarse porque el tamaño predeterminado es adecuado. Sin embargo, los programas que cargan muchas clases pueden necesitar una generación permanente más grande.

PermSize es un espacio de almacenamiento separado adicional para el valor -Xmx establecido por el usuario. La sección del montón reservada para la generación permanente contiene todos los datos reflexivos para la JVM. Debe ajustar el tamaño en consecuencia si su aplicación carga y descarga dinámicamente muchas clases para optimizar el rendimiento. Básicamente, el montón almacena los objetos y el gen perm mantiene información sobre los objetos dentro de él. Por lo tanto, cuanto más grande sea el montón, más grande debe ser el gen perm.

De forma predeterminada, MaxPermSize será de 32 MB para el cliente y de 64 MB para el servidor. Sin embargo, si no configura tanto PermSize como MaxPermSize, el montón general no aumentará a menos que sea necesario. Cuando configura tanto PermSize como MaxPermSize, por ejemplo, 192mb, el espacio adicional del montón se asignará cuando se inicie y se mantendrá asignado.

Para presentar una perspectiva ligeramente diferente, la IBM JVM no tiene un permgen, sino que va al sistema operativo y asigna trozos de memoria a medida que los necesita. (El rumor es que jrockit hace lo mismo, pero no puedo confirmarlo).

Esto es ventajoso porque no va a alcanzar un límite arbitrario (aparentemente) y necesita ajustarlo para situaciones de crecimiento legítimas.

Por otro lado, es un problema para las aplicaciones fuera de control (que esencialmente son clases de fugas): la JVM esencialmente consumirá toda la memoria en el espacio de direcciones. Esto puede provocar errores, donde el código nativo fallará repentinamente en las llamadas a malloc () o Java se romperá de manera extraña, como no poder asignar nuevos subprocesos (que consumen memoria para la pila). Otro inconveniente es que no proporciona "certeza de costos" acerca de la cantidad de memoria que consumirá la JVM.

Así que es una compensación: ¿cómo quieres fallar en los escenarios de "maldad potencial"?

Se utiliza para dimensionar la máxima generación permanente. En algunos algos o si usas muchas, muchas clases diferentes, podrías usar esto. Dale a este una lectura.

Pero sobre todo se utiliza como una pregunta en los exámenes ......

Tal vez quiera darle a su usuario la opción de cuánta memoria ocupará su aplicación, sí, el sistema operativo tiene un límite y lo detendrá de todos modos, pero tal vez el usuario quiera poder limitarlo en la configuración de las aplicaciones para que puedan hacerlo. haga otras cosas con esa memoria más adelante en el día sin bloquear su aplicación porque ya YA ocupa ese espacio y no puede liberarla porque la está utilizando. Por lo tanto, en el menú de configuración tiene un control deslizante de "la cantidad máxima de memoria que usamos" y pueden ajustarlo, lo que ajusta de manera correspondiente el MaxPermSize .