Personalmente, no consideraría a PermGen como una parte especial del montón.
Preferiría pensar en el montón como un área de memoria dedicada a almacenar instancias de objetos, mientras que PermGen es un área dedicada a almacenar definiciones de clases. Como resultado, el ciclo de vida de un montón está vinculado a una aplicación, mientras que el ciclo de vida de PermGen está vinculado a una JVM.
Uno de los mejores ejemplos de por qué una aplicación y su JVM pueden tener un ciclo de vida diferente es en un contenedor Java EE. En un servidor de aplicaciones, las aplicaciones se pueden implementar y anular la implementación sin reiniciar el servidor. Durante la cancelación del despliegue (o redespliegue), es fácil liberar todas las instancias de objetos, es decir, el espacio de pila, pero es bastante complicado borrar todas las clases cargadas por esta aplicación de PermGen porque la JVM aún puede hacer referencia a algunas de las clases.
Uno de esos casos son los controladores con fugas . Cuando se implementa una aplicación, se carga un controlador JDBC y se registra con DriverManager. Cuando se anula la implementación de esta aplicación, DriverManager sigue vivo y contiene una referencia al controlador, su cargador de clases original y todo lo que cargó este cargador de clases. Como resultado, se crea una pérdida de memoria en PermGen, pero no es culpa de la administración de memoria de la aplicación.
Es cierto que las JVM como JRocket no tienen PermGen en absoluto, todo se almacena en el montón. Solo en ese contexto puede llamar a PermGen una "parte especial" del montón. Incluso entonces, deberíamos ver PermGen y el montón de manera diferente, ya que tienen un propósito muy diferente y tienen tipos muy diferentes de pérdidas de memoria.
Actualización : en el JDK 8 de Oracle, PermGen se reemplaza por "Metaspace" y ahora es oficialmente parte del montón. Ya no necesitaremos sintonizar específicamente PermGen.