Java GC (falha de alocação)

129

Por que sempre "GC (falha na alocação)"?

VM do servidor Java HotSpot (TM) de 64 bits (25.25-b02) para linux-amd64 JRE ( 1.8.0_25 -b17),

CommandLine flags: 
-XX:CMSInitiatingOccupancyFraction=60 
-XX:GCLogFileSize=10485760 
-XX:+HeapDumpOnOutOfMemoryError 
-XX:InitialHeapSize=32212254720 
-XX:MaxHeapSize=32212254720 
-XX:NewRatio=10 
-XX:OldPLABSize=16 
-XX:ParallelGCThreads=4 
-XX:+PrintGC 
-XX:+PrintGCDetails 
-XX:+PrintGCTimeStamps 
-XX:+PrintStringTableStatistics 
-XX:+PrintTenuringDistribution 
-XX:StringTableSize=1000003 
-XX:SurvivorRatio=4 
-XX:TargetSurvivorRatio=50 
-XX:+UseCompressedClassPointers 
-XX:+UseCompressedOops
-XX:+UseParNewGC 
-XX:+UseConcMarkSweepGC
27.329: [GC (Allocation Failure) 27.329: [ParNew
Desired survivor size 44728320 bytes, new threshold 15 (max 15)
- age   1:   16885304 bytes,   16885304 total
: 349568K->16618K(436928K), 0.2069129 secs] 349568K->16618K(31369920K), 0.2070712 secs] [Times: user=0.78 sys=0.04, real=0.21 secs]


28.210: [GC (Allocation Failure) 28.210: [ParNew
Desired survivor size 44728320 bytes, new threshold 15 (max 15)
- age   1:   28866504 bytes,   28866504 total
- age   2:   12582536 bytes,   41449040 total
: 366186K->47987K(436928K), 0.2144807 secs] 366186K->47987K(31369920K), 0.2146024 secs] [Times: user=0.84 sys=0.01, real=0.22 secs]


29.037: [GC (Allocation Failure) 29.038: [ParNew
Desired survivor size 44728320 bytes, new threshold 2 (max 15)
- age   1:   28443488 bytes,   28443488 total
- age   2:   28386624 bytes,   56830112 total
- age   3:   12579928 bytes,   69410040 total
: 397555K->76018K(436928K), 0.2357352 secs] 397555K->76018K(31369920K), 0.2358535 secs] [Times: user=0.93 sys=0.01, real=0.23 secs]
user3644708
fonte

Respostas:

202

"Falha na alocação" é uma causa do ciclo do GC.

"Falha na alocação" significa que não há mais espaço no Eden para alocar objetos. Portanto, é causa normal de jovens GC.

A JVM mais antiga não estava imprimindo a causa do GC para ciclos menores de GC.

"Falha na alocação" é quase apenas uma causa possível para o GC menor. Outro motivo para o chute menor do GC poderia ser a fase de observação do CMS (se +XX:+ScavengeBeforeRemarkestiver ativada).

Alexey Ragozin
fonte
1
Obrigado. Apenas descubra que a JVM antiga não imprime Falha na Alocação.
user3644708
2
Eu não recebo essa resposta completamente, então deve ser evitado ou não? "é causa normal de jovens GC". O jovem GC é a escolha errada, então?
Thomas
7
Sim, este é um comportamento normal
Alexey Ragozin
183
O GC (falha na alocação) é uma má escolha de palavras para um evento que ocorrerá normalmente várias vezes ao dia. Esses engenheiros da JVM devem sair com mais frequência e tentar socializar no mundo real para que possam aprender termos mais amigáveis ​​que as pessoas entendem.
Salvador Valencia
79
@SalvadorValencia Tudo bem, as pessoas que lêem os logs do GC regularmente também não são exatamente "normais". :)
biziclop
8

"Falha na alocação" é a causa do chute do GC não está correto. É um resultado da operação do GC.

O GC entra em ação quando não há espaço para alocar (dependendo da região, o GC menor ou maior é executado). Uma vez realizado o GC, se o espaço for liberado o suficiente, mas se não houver tamanho suficiente, ele falhará. Falha na alocação é uma dessas falhas. O documento abaixo tem uma boa explicação https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/g1_gc.html

Kamal Rathod
fonte
1
"(...) ocorre uma falha na alocação (porque não há espaço para alocar os objetos ativos da região que está sendo evacuada) e é feita uma coleção completa do tipo parar o mundo (STW)." - No java 1.8, modo servidor, reproduzi uma breve pausa e os dois rastreamentos são impressos juntos: [GC (Falha na alocação) 2287742K-> 1148645K (2633216K), 0,4571912 s] [GC completo (ergonomia) 1148645K-> 1112141K (3184128K), 2,8563984 seg.]. Então eu upvote sua resposta ;-)
Jose Manuel Gomez Alvarez
-10

Quando o uso do CMS GC no jdk1.8 apareça esse erro, altero o G1 Gc para resolver esse problema.

 -Xss512k -Xms6g -Xmx6g -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:InitiatingHeapOccupancyPercent=70 -XX:NewRatio=1 -XX:SurvivorRatio=6 -XX:G1ReservePercent=10 -XX:G1HeapRegionSize=32m -XX:ConcGCThreads=6 -Xloggc:gc.log -XX:+HeapDumpOnOutOfMemoryError -XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps 
Hatter Bush
fonte
1
Por que isso foi rejeitado tantas vezes? Uma explicação seria útil.
Mike Stoddart
2
Porque é como dizer que você reescreveu seu programa no Rust e agora não possui essas mensagens?
simplylizz