Inlining em Java

Em C ++, posso declarar um método “inline” e o compilador provavelmente o incorpora. Tanto quanto eu entendo não existe essa palavra-chave em Java.

Inlining é feito se a JVM decidir fazê-lo? Posso influenciar essa decisão de alguma forma?

Algumas das outras respostas sugeriram que apenas methods finais podem ser embutidos – isso não é verdade, já que o HotSpot é inteligente o suficiente para ser capaz de embutir methods não finais, desde que eles ainda não tenham sido sobrescritos. Quando uma class é carregada, o que substitui o método, pode desfazer sua otimização. Obviamente, fazer o método final significa que nunca é necessário …

Basicamente, deixe a JVM fazer o seu trabalho – é provável que seja muito melhor saber onde inline do que você está.

Você tem uma situação em que está convencido de que a JVM não está fazendo um bom trabalho? Supondo que você esteja usando o HotSpot, já tentou usar a versão do servidor em vez do cliente? Isso pode fazer uma diferença enorme .

Embora o compilador java possa fazer inline (para methods short-bound), o inlining real será feito pelo compilador JIT. O compilador JIT (HotSpot) será capaz de, até mesmo, methods virtuais em linha. A melhor maneira de interagir com isso é escrever um código simples e conciso. Muito provavelmente, o código que usa o Reflection não permitirá inlining.

Espero que ajude.

‘Em C ++ eu posso declarar um método “inline” e o compilador irá in-line’ … ou não. O compilador está livre para fazer a function inline ou não e você não pode realmente afetar o resultado. É apenas uma dica para o compilador.

Em Java não existe tal coisa, o compilador (e mais tarde a VM ao executar otimizações) pode decidir ‘inline’ o método.

Observe que os methods finais têm maiores chances de serem inlined (o compilador não pode inline methods não finais, pois eles podem ser substituídos em classs derivadas). Com a VM moderna, uma otimização semelhante pode ser feita em tempo de execução. A VM sinalizará o tipo (para que possa executar verificações de tipo) e inline o código. Somente se a verificação falhar, ela retornará à chamada do método polimórfico original não otimizada.

Inlining é mais provável de acontecer se o método em questão for:

  • curto
  • final
  • não depende de nenhum método longo e não final

Como estas são as únicas circunstâncias em que a JVM pode ter certeza dos efeitos da chamada.

 class A { final int foo() { return 3; } } 

Dada esta class, qualquer chamada para foo () pode ser substituída pela constante “3”. Qualquer máquina virtual Java1 pode fazer isso, porque a palavra-chave final determina explicitamente que não é possível ter uma subclass que substitua “int foo ()”.

Inlining o método fornece os seguintes benefícios no site da chamada:

  • Nenhuma chamada de método
  • Nenhum despacho dynamic
  • Possível dobrar constantemente o valor, por exemplo. “a.foo () + 2” torna-se 5 sem código executado em
    tempo de execução.

No passado, os programadores frequentemente inseriam a palavra-chave final exatamente por esse motivo . Ou, para facilitar o inlining e aumentar a velocidade de execução, eles combinariam muitos methods menores em um método maior. Mas, de muitas maneiras, essas técnicas eliminam toda a facilidade de modularização e reutilização incorporadas à linguagem de programação.

A JVM moderna, como a Java HotSpot VM, é capaz de embutir a class sem a final . palavra-chave **.

( http://java.sun.com/developer/technicalArticles/Networking/HotSpot/inlining.html )

Leia isto para o comportamento Inlining. http://www.javacoffeebreak.com/articles/thinkinginjava/comparingc++andjava.html

Diz que os methods finais podem ser alinhados, mas nem sempre.

Sim, se a JVM decidir fazê-lo, poderá. Formas de influenciar incluem definir o método como estático ou como final.

Naturalmente, o mais importante é que a estrutura do método precisa estar em linha. Short ajuda, mas o mais importante é que ele precisa apenas usar suas variables ​​locais e seus parâmetros, nenhum campo e chamadas mínimas de método para outros methods na mesma class.

No entanto, você não deve procurar fazer essas otimizações prematuramente, você pode realmente estar piorando as coisas (porque você poderia estar em curto-circuito com outras otimizações potenciais). A JVM às vezes perceberá que um método pode ser embutido sem essas dicas.

Ao comparar uma function normal e function final (que é dito ser inline pela JVM), tenho visto que não há melhoria de desempenho entre eles. Talvez a sobrecarga da chamada de function já seja muito baixa.

Nota: usei o algoritmo de desfoque de checkbox para avaliar o desempenho.