Un cambio en el recolector de basura G1 de Java reduciría la memoria y la sobrecarga de procesamiento y aceleraría la ejecución del compilador JIT (justo a tiempo) de optimización C2 de Java, beneficiando las implementaciones en la nube, según una propuesta de la comunidad Java.
El Propuesta abiertaJDK simplificaría la implementación de las barreras de G1, que registran información sobre los accesos a la memoria de las aplicaciones, al cambiar su expansión desde las primeras etapas del proceso de compilación del C2 JIT a más adelante, afirma la propuesta.
Detrás de esta propuesta está la creciente popularidad de las tecnologías basadas en la nube. Java implementaciones, lo que ha llevado a un mayor enfoque en reducir la sobrecarga general de JVM. Los objetivos del plan incluyen reducir el tiempo de ejecución de C2 cuando se utiliza el recopilador G1, hacer que las barreras de G1 sean comprensibles para los desarrolladores de HotSpot que carecen de un conocimiento profundo de C2 y garantizar que C2 conserve invariantes sobre el orden relativo de los accesos a la memoria, los puntos seguros y barreras. Otro objetivo es preservar la calidad del código generado C2 en términos de velocidad y tamaño.
No es un objetivo de la propuesta mantener la actual expansión temprana de la barrera de G1 como un modo heredado, afirma la propuesta, y agrega que el cambio a la expansión tardía de la barrera debe ser completamente transparente, por lo que un modo heredado es innecesario. La propuesta se creó a mediados de diciembre de 2023 y se actualizó el 9 de abril de 2024.
Al explicar la motivación del plan, la propuesta cita la creciente popularidad de las implementaciones en la nube y los importantes gastos generales que suponen los compiladores de optimización JIT como C2. Los experimentos preliminares muestran que la expansión temprana de las barreras G1 aumenta la sobrecarga de C2 entre un 10% y un 20%, según la aplicación. Reducir estos gastos generales es clave para que la plataforma Java se adapte mejor a la nube, afirma la propuesta.
Otro contribuyente importante a la sobrecarga de JVM es el recolector de basura (GC). Desacoplar la instrumentación de barrera G1 de los componentes internos de C2 permitiría a los desarrolladores de GC optimizar y reducir aún más la sobrecarga de G1, mediante mejoras algorítmicas y microoptimizaciones de bajo nivel.
Finalmente, la propuesta señala que el alcance para que C2 optimice el código de barrera en sí es limitado y que se podría generar código de calidad similar si los detalles de implementación de la barrera se ocultaran de C2 y se expandieran solo al final del proceso de compilación. Por lo tanto, los autores proponen ampliar las barreras del G1 lo más tarde posible en el proceso de compilación del C2.
Copyright © 2024 IDG Communications, Inc.