Código compilado em java 8 vs código compilado em java 11

Question

Atualmente, temos o código compilado em Java 8, mas o estamos executando no Java 11 VM. Agora estamos tentando mover nosso código para o tempo de compilação do Java 11 também. Quer saber se há algum benefício em código compilado em Java 8 versus código compilado em Java 11 em termos de desempenho, já que ambos os compiladores produzirão arquivos de classe diferentes (bytecode)? Como um difere do outro em termos de eficiência?

Answer 1

javacnão é um compilador de otimização , portanto, em geral, não espere que ele produza bytecode "mais rápido" de uma versão para outra. A otimização é um trabalho da JVM.

Enquanto isso, o Java Compiler oferece suporte a novos recursos de linguagem e pode oferecer suporte a novos recursos JVM. Alguns deles realmente têm implicações de desempenho. Os exemplos mais notáveis ​​em JDK 9 - JDK 11 são os seguintes.

1. JEP 280: Indificar Concatenação de String (JDK 9).

   Este JEP muda a maneira como as expressões de concatenação de strings são compiladas. Antes do JDK 9, a +expressão de string foi traduzida para

   new StringBuilder().append()...append().toString();
   

   Embora o JIT reconheça essas cadeias e tente otimizá-las em tempo de execução, essa otimização é frágil e nem sempre funciona como esperado. Compilar a concatenação de string invokedynamicdá à JVM mais liberdade para produzir um código melhor. Você pode encontrar a explicação detalhada e benchmarks nas notas deste JEP.

2. JEP 181: Controle de acesso baseado em Nest (JDK 11)

   Este JEP resolve o problema de acesso a membros privados de classes aninhadas. Antes do JDK 11, o Java Compiler gerava métodos de ponte sintética para eles ( exemplo ).

   À primeira vista, isso não tem nada a ver com desempenho. No entanto, em casos marginais, um método sintético adicional pode quebrar o inlining devido ao limite de profundidade do inlining.

   O Nest-Based Access Control permite que as classes nestmate acessem membros privados umas das outras sem pontes sintéticas, reduzindo assim o risco de degradação acidental do desempenho.

Atualizar

Anteriormente, incluí JDK-8175883: Geração de Bytecode para Enhanced for Loop nesta lista, mas como @Holger notou nos comentários, essa "otimização" não funcionou de verdade.

Conclusão

As alterações no Java Compiler estão principalmente relacionadas a novos recursos de linguagem / JVM. A otimização do nível de bytecode não é um objetivo. No entanto, algumas dessas alterações podem (indiretamente) afetar o desempenho também. De qualquer forma, os possíveis benefícios de desempenho da recompilação do código geralmente são tão pequenos que você nem notará em um aplicativo real.