¿Puede el tamaño de almacenamiento dinámico de JVM ser dinámico?

Question

El argumento JVM -Xmx permite establecer el máximo tamaño de almacenamiento dinámico para la JVM en algún valor. Pero, ¿hay alguna manera de hacer que ese valor sea dinámico? En otras palabras, quiero decirle a la JVM "mira, si lo necesitas, simplemente sigue sacando RAM del sistema hasta que el sistema se apague".

Motivo de dos partes para preguntar: En primer lugar, la aplicación en cuestión puede usar una amplia gama de ram dependiendo de lo que el usuario esté haciendo, por lo que los valores mínimo y máximo conceptuales están bastante separados. En segundo lugar, parecería que la JVM reserva el espacio máximo dinámico de la memoria virtual en el momento del arranque. Esta aplicación en particular se ejecuta en una amplia variedad de hardware, por lo que elegir un espacio de almacenamiento dinámico de "talla única" es difícil, ya que tiene que ser lo suficientemente bajo para ejecutarse en hardware de gama baja, pero realmente lo haríamos. les gusta poder aprovechar las máquinas realmente carnosas si están disponibles.

Answer 1

Pero, ¿hay alguna manera de hacer que ese valor sea dinámico?

Literalmente, no. El tamaño máximo de almacenamiento dinámico se establece en el momento de inicio de JVM y no se puede aumentar.

En la práctica, podría simplemente establezca el tamaño máximo de almacenamiento dinámico tan grande como lo permita su plataforma, y ​​deje que la JVM haga crecer el montón según lo necesite. Existe un riesgo obvio al hacer esto; es decir, que su aplicación hará y utilizará toda la memoria y hará que la máquina del usuario se detenga. Pero ese riesgo está implícito en tu pregunta.

EDITAR

Vale la pena señalar que hay varias opciones de ajuste -XX... GC que le permiten ajustar la forma en que la JVM expande el almacenamiento dinámico (hasta el máximo).

Otra posibilidad es dividir su aplicación en 2 partes. La primera parte de la aplicación hace toda la preparación necesaria para determinar el "tamaño" del problema. A continuación, resuelve un tamaño máximo de almacenamiento dinámico apropiado y lanza la segunda parte de la aplicación que tiene mucha memoria en una nueva JVM.

• Esto solo funciona si la aplicación puede dividirse sensiblemente como se indicó anteriormente.

• Esto solo funciona si es posible calcular el tamaño del problema. En algunos casos, calcular el tamaño del problema equivale a calcular el resultado.

• No está claro que obtendrá un mejor rendimiento general que si simplemente deja que el montón crezca hasta un tamaño máximo.

Answer 2

No es así. Se podría, y probablemente debería:

-Xmx90% // 90% of physical memory 

Sin embargo, un defecto implícita, 100%, no es una buena idea proabbly.

Un programa escrito en un idioma que no es de GC administra su memoria con mucha diligencia, podará cualquier basura lo antes posible. Tiene sentido permitirle obtener cualquier memoria que solicite, asumiendo que es responsable de la pronta eliminación de basura.

Un lenguaje de GC es diferente. Recoge basura solo cuando es necesario. Mientras haya espacio, no le importa que la basura persista. Si pudiera obtener toda la memoria que le gustaría tener, obtendría toda la memoria de la computadora.

Por lo tanto, un programador de GC ya no tiene que preocuparse por deshacerse de cada pieza de basura, pero aún debe tener una idea general de la relación tolerable basura/objeto vivo, e instruir GC con -Xmx.

Answer 3

Básicamente, no se puede adaptar a diferentes usuarios de hardware utilizando Java puro: es cuando un poco de secuencias de comandos shell/lote puede ser útil.

lo hago sólo que en OS X y Linux: Tengo un poco de fiesta shell script que se encarga de encontrar los parámetros correctos de JVM en función del hardware se ejecuta la aplicación y luego llamar a la JVM.

Tenga en cuenta que si usted está proporcionando una aplicación Java de escritorio, entonces es posible que desee utilizar algo como IzPack proporcionar a los usuarios un instalador:

http://izpack.org

no sé en absoluto si Java Web Start se puede utilizar para proporcionar diferentes parámetros de JVM según la configuración del usuario (probablemente no, y JWS en realidad necesita mucho tiempo de todos modos si planea proporcionar una aplicación de escritorio de aspecto profesional).