Uma mudança no coletor de lixo G1 do Java reduziria a sobrecarga de memória e processamento e aceleraria a execução do compilador JIT (just-in-time) otimizador C2 do Java, beneficiando implantações em nuvem, sob uma proposta da comunidade Java.
A proposta do OpenJDK simplificaria a implementação das barreiras do G1, que registram informações sobre os acessos à memória do aplicativo, mudando sua expansão do início do pipeline de compilação do JIT C2 para mais tarde, afirma a proposta.
Subjacente a esta proposta está a crescente popularidade das implantações Java baseadas em nuvem, o que levou a um foco mais forte na redução da sobrecarga geral da JVM. Os objetivos do plano incluem reduzir o tempo de execução de C2 ao usar o coletor G1, tornar as barreiras G1 compreensíveis para desenvolvedores de HotSpot que não possuem um conhecimento profundo de C2 e garantir que C2 preserve invariantes sobre a ordem relativa de acessos à memória, pontos seguros e barreiras. Outro objetivo é preservar a qualidade do código gerado em C2 em termos de velocidade e tamanho.
Não é um objetivo da proposta manter a atual expansão inicial da barreira do G1 como um modo legado, afirma a proposta, acrescentando que a mudança para a expansão tardia da barreira deve ser totalmente transparente, pelo que um modo legado é desnecessário. A proposta foi criada em meados de dezembro de 2023 e atualizada em 9 de abril de 2024.
Ao explicar a motivação para o plano, a proposta cita a crescente popularidade das implantações em nuvem e a sobrecarga significativa incorrida pelos compiladores de otimização JIT, como o C2. Experimentos preliminares mostram que a expansão antecipada das barreiras G1 aumenta a sobrecarga C2 em cerca de 10% a 20%, dependendo da aplicação. Reduzir essa sobrecarga é fundamental para tornar a plataforma Java mais adequada para a nuvem, afirma a proposta.
Outro contribuidor importante para a sobrecarga da JVM é o coletor de lixo (GC). A dissociação da instrumentação da barreira G1 dos componentes internos do C2 permitiria aos desenvolvedores de GC otimizar e reduzir ainda mais a sobrecarga do G1, por meio de melhorias algorítmicas e micro-otimizações de baixo nível.
Finalmente, a proposta observa que o escopo para C2 otimizar o código de barreira em si é limitado e que código de qualidade semelhante poderia ser gerado se os detalhes de implementação da barreira fossem ocultados de C2 e expandidos apenas no final do pipeline de compilação. Os autores propõem, portanto, expandir as barreiras G1 o mais tarde possível no pipeline de compilação do C2.
