¿Por qué la JVM tarda en comenzar?

Solo para tener en cuenta algunas soluciones:

Existen dos mecanismos que permiten un arranque más rápido de JVM. El primero, es el mecanismo de intercambio de datos de clase, que es compatible desde la actualización 21 de Java 6 (solo con la VM Cliente de HotSpot, y solo con el recolector de basura serie que yo sepa)

Para activarlo necesita establecer -Xshare (en algunas implementaciones: -Xshareclasses ) opciones JVM.

Para leer más sobre la función puede visitar: Datos de clase compartir

El segundo mecanismo es un Java Quick Starter. Permite precargar clases durante el inicio del sistema operativo, consulte: Java Quick Starter para más detalles.

Ejecutar una aplicación Java trivial con el cliente JVM 1.6 (Java 6) parece instantáneo en mi máquina. Sun ha intentado ajustar la JVM del cliente para un inicio más rápido (y la JVM del cliente es la predeterminada), por lo que si no necesita muchos archivos jar adicionales, el inicio debería ser rápido.

Si está utilizando el HotSpot de Sun para x86_64 (compilado a 64 bits), tenga en cuenta que la implementación actual solo funciona en modo servidor, es decir, precompila cada clase que carga con optimización completa, mientras que la versión de 32 bits también admite el modo cliente, que generalmente pospone la optimización y optimiza solo las partes más intensivas de la CPU, pero tiene tiempos de inicio más rápidos.

Véase para instancia:

• http://en.wikipedia.org/wiki/64-bit#32_vs_64_bit
• http://java.sun.com/docs/hotspot/HotSpotFAQ.html#64bit_compilers

Dicho esto, al menos en mi máquina (Linux x86_64 con kernel de 64 bits), la versión de HotSpot de 32 bits soporta tanto el modo cliente como el servidor (a través de las banderas-client y-server), pero por defecto el modo servidor, mientras que la versión de 64 bits solo soporta el modo servidor.

Realmente depende de lo que esté haciendo durante la puesta en marcha. Si ejecuta la aplicación Hello World, tarda 0.15 segundos en mi máquina.

Sin embargo, Java es más adecuado para ejecutarse como un cliente o un servidor/servicio, lo que significa que el tiempo de inicio no es tan importante como el tiempo de conexión (aproximadamente 0.025 ms) o el tiempo de respuesta de ida y vuelta (

Hay una serie de razones:

• muchos jar s para cargar
• verificación (asegurarse de que el código no hace cosas malas)
• JIT (compilación justo a tiempo) overhead

No estoy seguro sobre el CLR, pero creo que a menudo es más rápido porque almacena en caché una versión nativa de ensamblados para la próxima vez (por lo que no necesita JIT). CPython se inicia más rápido porque es un intérprete, y IIRC, no hace JIT.

Además de las cosas ya mencionadas (cargando clases, esp. de JARs comprimidos); corriendo en modo interpretado antes de que HotSpot compile bytecode de uso común; y sobrecarga de compilación de HotSpot, también hay un poco de inicialización de una sola vez realizada por las propias clases JDK. Muchas optimizaciones se realizan a favor de sistemas de ejecución más larga donde la velocidad de inicio es menos preocupante.

Y en cuanto a la canalización de estilo unix: ciertamente NO desea iniciar y reiniciar múltiples JVM tiempo. Eso no va a ser eficiente. El encadenamiento de herramientas debería ocurrir dentro de JVM. Esto no se puede mezclar fácilmente con herramientas Unix que no sean Java, excepto iniciando tales herramientas desde dentro de JVM.

Todas las máquinas virtuales con un sistema de tipo rico como Java o CLR no serán instantáneas en comparación con sistemas menos ricos como los que se encuentran en C o C++. Esto se debe en gran parte a que muchas cosas están sucediendo en la máquina virtual, muchas clases se inicializan y son requeridas por un sistema en ejecución. Las instantáneas de un sistema inicializado ayudan, pero aún cuesta cargar esa imagen de nuevo en la memoria, etc.

Un simple hello world estilo una clase liner con un main todavía requiere mucho para ser cargado e inicializado. Verificar la clase requiere una gran cantidad de verificación y validación de dependencias, todo lo cual cuesta tiempo y muchas instrucciones de CPU para ser ejecutadas. Por otro lado, un programa C no hará nada de esto y contará con unas pocas instrucciones y luego invocará la función de impresora.