¿Por qué el Hot Swap de depuración de Java se limita a cambios dentro del método?
debugging hotdeploy (4)
He pasado por tutorial de despliegue caliente y funciona. Pero tengo preguntas sobre las limitaciones (punto 3) es decir
La implementación en caliente ha admitido los cambios de código solo en la implementación del método. Si agrega una nueva clase o un nuevo método, aún es necesario reiniciar.
Básicamente, ¿por qué no necesitamos reiniciar el servidor si realizo cambios en el método existente pero es necesario en caso de agregar un método o una clase?
Entiendo cómo funciona: - Cuando realizo los cambios en un método existente o introduje un nuevo método, Eclipse colocará el archivo en la ubicación correcta debajo del servidor web. Si el cargador de clases ya ha cargado la clase en el espacio perm gen, la descargará del espacio permgen y cargará la nueva internamente sin reiniciar el servidor para que se reflejen los nuevos cambios (código de bytes). Es eso correcto ?
En caso afirmativo, ¿por qué la implementación en caliente no funciona con nuevos métodos y nuevos archivos de clase?
Como nota al margen, la especificación en sí no está limitada .
Simplemente sucede que algunas de las implementaciones disponibles, incluida la Implementación de Referencia ubicua, son limitadas.
Después de conectarse a una máquina virtual remota, puede verificar si permite agregar métodos o redefinir clases .
El razonamiento es bastante complicado y, en realidad, solo lo saben las personas con un conocimiento íntimo de la JVM y cómo gestiona la memoria. Hay una explicación decente en esta página (aunque es realmente un anuncio del producto JRebel): desplácese hasta la sección titulada ¿Por qué HotSwap se limita a los cuerpos de los métodos? .
Lo esencial: hay dos factores principales que impiden que HotSwap maneje los cambios estructurales en las clases: JIT y asignación de memoria.
El compilador JIT (Just In Time) en la JVM optimiza el bytecode después de que las clases se hayan cargado y ejecutado varias veces, básicamente incorporando muchas llamadas para aumentar el rendimiento. Implementar esa característica de manera segura y efectiva en un entorno donde las firmas y la estructura de las clases pueden cambiar sería un desafío importante.
Otros problemas rodean lo que sucedería con respecto a la administración de memoria si las estructuras de clase pudieran cambiar. La JVM tendría que modificar las instancias de clases existentes, lo que significaría reubicarlas en otras partes del almacenamiento del montón. Por no hablar de tener que reubicar los objetos de clase en sí mismos. La gestión de memoria de la JVM ya es increíblemente compleja y altamente optimizada; tales cambios solo aumentarían la complejidad y potencialmente reducirían el rendimiento del compilador JIT (y probablemente conducirían a errores adicionales).
Creo que es seguro asumir que los ingenieros de JVM no han estado dispuestos a aceptar las compensaciones de huella de errores y rendimiento que se necesitarían para admitir esta función. Es por eso que productos como JRebel y otros han llegado a existir.
La respuesta provista por E-Riz ya tiene una buena explicación de las razones por las cuales la tecnología Java HotSwap estándar solo admite las modificaciones a los métodos existentes y no la adición de nuevas clases o métodos a las clases.
Sin embargo, como se ha descrito en una discusión de SO relacionada, el nivel de intercambio en caliente que se obtiene depende de la cadena de herramientas que utilice. Por lo tanto, si termina agregando el complemento JRebel, podría realizar un intercambio en caliente incluso cuando se hayan agregado nuevos métodos y clases.
Hay otro proyecto: Agente de intercambio en caliente : este es típicamente un agente de Java que se puede usar para ejecutar su contenedor Java y puede activarlo usando un par de parámetros de línea de comandos (como se menciona en el quickstart ).
Usted puede si ejecuta su java en un vm smalltalk. Smalltalk ha estado haciendo esto básicamente para siempre, y es una de las razones por las que los Smalltalkers tienden a hacer un desarrollo impulsado por el depurador como una forma superior de desarrollo impulsado por pruebas. Smalltalk vms realiza la limpieza requerida de las estructuras de datos de memoria. En Eliot Miranda''s Spur (para Squeak, Pharo and Cuis) y Gemstone que se hace perezosamente, pero de lo contrario es posible que tenga que esperar a que todos los objetos se migren. La implementación de referencia java vm probablemente tenga más optimizaciones que cualquier vm smalltalk que pueda ejecutar java en cajeros automáticos