Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8083298 | emb-9 | Vladimir Kozlov | P3 | Resolved | Fixed | team |
JDK-8067536 | 8u45 | Vladimir Kozlov | P3 | Resolved | Fixed | b01 |
JDK-8066653 | 8u40 | Vladimir Kozlov | P3 | Resolved | Fixed | b18 |
JDK-8070924 | emb-8u47 | Vladimir Kozlov | P3 | Resolved | Fixed | team |
This issue may be observed with running a simple Maven command:
$ mvn dependency:help
Then, you may observe the significant stall after Maven completes (prints "BUILD SUCCESS" message).
A simple profiling shows we spend most of the time after the main application thread exits in C2 compiler thread doing:
ConnectionGraph::add_fields_to_worklist(FieldNode*,PointsToNode*) + 0x000000B4
ConnectionGraph::add_field_uses_to_worklist(FieldNode*) + 0x00000192
ConnectionGraph::complete_connection_graph(GrowableArray<PointsToNode*>&,GrowableArray<JavaObjectNode*>&,GrowableArray<JavaObjectNode*>&,GrowableArray<FieldNode*>&) + 0x00000488
ConnectionGraph::compute_escape() + 0x000006EF
ConnectionGraph::do_analysis(Compile*,PhaseIterGVN*) + 0x0000010C
Compile::Optimize() + 0x000010BA
Compile::Compile(ciEnv*,C2Compiler*,ciMethod*,int,bool,bool,bool) + 0x00001088
C2Compiler::compile_method(ciEnv*,ciMethod*,int) + 0x000001A3
CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x000008AF
CompileBroker::compiler_thread_loop() + 0x000004E3
JavaThread::thread_main_inner() + 0x000000E9
java_start(Thread*) + 0x000000EF
collector_root + 0x000001B6, line 1221 in "dispatcher.c"
start_thread + 0x000000BA
There are other simple commands that are affected by this, probably those long enough to kick C2 in.
I've checked this reproduces with current jdk8u and jdk9/dev.
$ mvn dependency:help
Then, you may observe the significant stall after Maven completes (prints "BUILD SUCCESS" message).
A simple profiling shows we spend most of the time after the main application thread exits in C2 compiler thread doing:
ConnectionGraph::add_fields_to_worklist(FieldNode*,PointsToNode*) + 0x000000B4
ConnectionGraph::add_field_uses_to_worklist(FieldNode*) + 0x00000192
ConnectionGraph::complete_connection_graph(GrowableArray<PointsToNode*>&,GrowableArray<JavaObjectNode*>&,GrowableArray<JavaObjectNode*>&,GrowableArray<FieldNode*>&) + 0x00000488
ConnectionGraph::compute_escape() + 0x000006EF
ConnectionGraph::do_analysis(Compile*,PhaseIterGVN*) + 0x0000010C
Compile::Optimize() + 0x000010BA
Compile::Compile(ciEnv*,C2Compiler*,ciMethod*,int,bool,bool,bool) + 0x00001088
C2Compiler::compile_method(ciEnv*,ciMethod*,int) + 0x000001A3
CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x000008AF
CompileBroker::compiler_thread_loop() + 0x000004E3
JavaThread::thread_main_inner() + 0x000000E9
java_start(Thread*) + 0x000000EF
collector_root + 0x000001B6, line 1221 in "dispatcher.c"
start_thread + 0x000000BA
There are other simple commands that are affected by this, probably those long enough to kick C2 in.
I've checked this reproduces with current jdk8u and jdk9/dev.
- backported by
-
JDK-8066653 C2 escape analysis prevents VM from exiting quickly
-
- Resolved
-
-
JDK-8067536 C2 escape analysis prevents VM from exiting quickly
-
- Resolved
-
-
JDK-8070924 C2 escape analysis prevents VM from exiting quickly
-
- Resolved
-
-
JDK-8083298 C2 escape analysis prevents VM from exiting quickly
-
- Resolved
-
- relates to
-
JDK-8041984 CompilerThread seems to occupy all CPU in a very rare situation
-
- Resolved
-