O que são ReservedCodeCacheSize e InitialCodeCacheSize?

Alguém pode explicar quais são as opções JVM ReservedCodeCacheSizee quais InitialCodeCacheSizesão? Especificamente quando / por que eu iria querer mudar isso? Como decido qual é o tamanho certo?

É o que dizem os documentos:

-XX: ReservedCodeCacheSize = 32m Tamanho do cache de código reservado (em bytes) - tamanho máximo do cache de código. [Solaris 64 bits, amd64 e -server x86: 2048m; em 1.5.0_06 e anterior, Solaris de 64 bits e and64: 1024m.]

ReservedCodeCacheSize(e InitialCodeCacheSize) é uma opção para o compilador (just-in-time) do Java Hotspot VM. Basicamente, ele define o tamanho máximo do cache de código do compilador.

O cache pode ficar cheio, o que resulta em avisos como os seguintes:

Java HotSpot(TM) 64-Bit Server VM warning: CodeCache is full. Compiler has been disabled.
Java HotSpot(TM) 64-Bit Server VM warning: Try increasing the code cache size using -XX:ReservedCodeCacheSize=
Code Cache  [0x000000010958f000, 0x000000010c52f000, 0x000000010c58f000)
 total_blobs=15406 nmethods=14989 adapters=362 free_code_cache=835Kb largest_free_block=449792

É muito pior quando seguido por Java HotSpot(TM) Client VM warning: Exception java.lang.OutOfMemoryError occurred dispatching signal SIGINT to handler- the VM may need to be forcibly terminated.

Quando definir esta opção?

1. ao ter falhas do compilador de Hotspot
2. para reduzir a memória necessária para a JVM (e, portanto, arriscando falhas do compilador JIT)

Normalmente você não mudaria este valor. Eu acho que os valores padrão são bem balanceados porque esses problemas ocorrem apenas em ocasiões muito raras (na minha experiência).

@jeha responde a tudo que eu queria saber dessa pergunta, além de qual valor definir os parâmetros. Como não escrevi o código que estava implantando, não tive muita visibilidade da área de cobertura de memória que ele tinha.

No entanto, você pode usar jconsole para anexar ao seu processo Java em execução e, em seguida, usar a guia 'Memória' para descobrir o tamanho do Cache de Código. Para completar, as etapas são (ambiente de VM Linux, embora eu tenha certeza de que outros ambientes são semelhantes):

1. Abra o jconsole em sua máquina
2. Encontre o ID de processo correto e anexe o jconsole a ele (isso levará alguns minutos)
3. Navegue até a guia 'Memória'
4. Na lista suspensa 'Gráfico:', selecione 'Pool de memória "Cache de código"'

5. Novamente, pode demorar alguns minutos para que a tela seja atualizada e, em seguida, você deverá ver algo como:

   Como você pode ver, meu cache de código está usando aproximadamente 49 MB. Neste ponto eu ainda tinha o padrão que a documentação (e @jeha) diz é de 48 MB. Certamente uma grande motivação para eu aumentar a configuração!

   Ben.

   ---

   1024 MB por padrão provavelmente era um exagero, mas 48 MB por padrão parece ser insuficiente ...

Uma boa experiência de aprendizado com a equipe de engenharia do Even e os desafios que eles enfrentaram ao migrar para o jdk 8.

http://engineering.indeedblog.com/blog/2016/09/job-search-web-app-java-8-migration/

Conclusão: Jdk 8 precisa de mais cache de código han JDK 7

O tamanho do codecache padrão para JRE 8 é cerca de 250 MB, cerca de cinco vezes maior do que o tamanho padrão de 48 MB para JRE 7. Nossa experiência é que o JRE 8 precisa desse codecache extra. Trocamos cerca de dez serviços para o JRE 8 até agora e todos eles usam cerca de quatro vezes mais codecache do que antes.

de https://blogs.oracle.com/poonam/entry/why_do_i_get_message :

A seguir estão dois problemas conhecidos no jdk7u4 + com relação à liberação do CodeCache:

1. O compilador pode não ser reiniciado mesmo depois que a ocupação do CodeCache cai para quase metade após a descarga de emergência.
2. A liberação de emergência pode causar alto uso da CPU pelos threads do compilador, levando à degradação geral do desempenho.

Esse problema de desempenho e o problema do compilador não ser reativado foram resolvidos no JDK8. Para contornar isso em JDK7u4 +, podemos aumentar o tamanho do cache de código usando a opção ReservedCodeCacheSize, definindo-o para um valor maior do que a área de cobertura do código compilado para que o CodeCache nunca fique cheio. Outra solução para isso é desativar o CodeCache Flushing usando a opção JVM -XX: -UseCodeCacheFlushing.

Os problemas mencionados acima foram corrigidos no JDK8 e suas atualizações.

Portanto, essa informação pode valer a pena mencionar para sistemas em execução no JDK 6 (com a liberação de código desativada) e 7.