2015-01-28 27 views
13

Napisałem aplikację serwera w Javie 8 i uruchomiłem ją z java 1.8.0u25.Wątek JIT Java 8 wydaje się popadać w nieskończoną pętlę

Działa dobrze przez pierwsze kilka godzin, ale po otrzymaniu około 5k ~ 10k wniosków, wątek procesu VM wykorzystuje 100% jednego z procesorów.

Więc próbowałem jstack dla procesu VM, by sprawdzić, co było problematyczne nici, a okazało się, że gwint (id wątek był 14303 = 0x37df) był "C2 CompilerThread0":

"C2 CompilerThread0" #6 daemon prio=9 os_prio=0 tid=0x00002aaabc12a000 nid=0x37df runnable [0x0000000000000000] 
    java.lang.Thread.State: RUNNABLE 

I z jstack -m , ślad stosu wątku było jak:

----------------- 14303 ----------------- 
0x00002b99b67693c3 _ZN16PhaseMacroExpand27process_users_of_allocationEP8CallNode + 0x2a3 
0x00002b99b676ec3b _ZN16PhaseMacroExpand23eliminate_allocate_nodeEP12AllocateNode + 0x1cb 
0x00002b99b676ee65 _ZN16PhaseMacroExpand21eliminate_macro_nodesEv + 0x1a5 
0x00002b99b6772769 _ZN16PhaseMacroExpand18expand_macro_nodesEv + 0x19 
0x00002b99b640b01b _ZN7Compile8OptimizeEv + 0xa6b 
0x00002b99b640c53c _ZN7CompileC1EP5ciEnvP10C2CompilerP8ciMethodibbb + 0x13bc 
0x00002b99b635f9c8 _ZN10C2Compiler14compile_methodEP5ciEnvP8ciMethodi + 0x198 
0x00002b99b6414c6a _ZN13CompileBroker25invoke_compiler_on_methodEP11CompileTask + 0xc8a 
0x00002b99b6417650 _ZN13CompileBroker20compiler_thread_loopEv + 0x620 
0x00002b99b69a2e8f _ZN10JavaThread17thread_main_innerEv + 0xdf 
0x00002b99b69a2fbc _ZN10JavaThread3runEv + 0x11c 
0x00002b99b6860d48 _ZL10java_startP6Thread + 0x108 

i za każdym razem próbował jstack -m, ślad stosu tego wątku było wszystko jedno, ale liczba obok metody u (licznik programu?) góra st ack _ZN16PhaseMacroExpand27process_users_of_allocationEP8CallNode był 0x290, 0x2b1, 0x2a3 lub 0x29f.

C2 CompilerThread0 wygląda jak wątek robiący kompilację JIT, a ślad stosu wygląda tak, jakby wpadł w nieskończoną pętlę lub coś.

Zastanawiam się, czy może to być błąd kompilatora JIT JVM. Jeśli tak, to jak mogę określić, która metoda mojej aplikacji sprawia, że ​​JVM jest szalona i jak mogę rozwiązać (lub obejść) ten problem? Próbowałem opcji -XX:+PrintCompilation, ale to niewiele pomogło, ponieważ nie pokazało, który wątek skompilował jaką metodę. Jeśli to nie jest problem JVM, co może sprawić, że to się stanie?

+4

To wydaje się należeć do analizy ucieczki, więc wyłączenie go za pomocą '-XX: -DoEscapeAnalysis' może poprawić problem. Istnieje opcja '-XX: + PrintEliminateAllocations', aby zobaczyć jej efekty, jednak wymaga ona kompilacji debugowania JVM. – Holger

+0

Jeśli jest to błąd, sugeruję wypróbowanie aktualizacji Java 8 31 lub aktualizacji 40, ponieważ może to być naprawione. –

+1

Próbowałem Java 8 u31 po poradę @ PeterLawrey, ale ten sam problem dzieje się ponownie .. – JJS

Odpowiedz

6

Rzeczywiście wygląda na błąd kompilatora JIT, prawdopodobnie w optymalizacji eliminacji alokacji.
Spróbuj uruchomić przy użyciu opcji JVM -XX:-EliminateAllocations.

Możesz również dodać -XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation, aby wygenerować szczegółowy dziennik kompilacji z osobnym plikiem wyjściowym dla każdego wątku kompilatora.

Powiązane problemy