| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-2174483 | 7 | Vladimir Kozlov | P4 | Closed | Fixed | b51 |
| JDK-2180515 | 6u18 | Vladimir Kozlov | P4 | Resolved | Fixed | b01 |
Running server VM fastdebug build with -XX:+DoEscapeAnalysis could lead to:
# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc: SuppressErrorAt=\sched.cpp:2293
#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (c:\...\sources\hotspot\src\share\vm\opto\sched.cpp:2293), pid=4076, tid=2156
# Error: assert(prev_selected_node != chosen_node,"Trace_Sched::select_node is in an infinite loop")
#
The code inspection has shown that the bug is in common code.
This assert happened in the new port sources.
Also it is not a big problem - the only condition to generate correct code
is to have SafePointScalarObject node referencing only one Safepoint node
for which it was created. And this is why there was the fix to make it pinned.
# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc: SuppressErrorAt=\sched.cpp:2293
#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (c:\...\sources\hotspot\src\share\vm\opto\sched.cpp:2293), pid=4076, tid=2156
# Error: assert(prev_selected_node != chosen_node,"Trace_Sched::select_node is in an infinite loop")
#
The code inspection has shown that the bug is in common code.
This assert happened in the new port sources.
Also it is not a big problem - the only condition to generate correct code
is to have SafePointScalarObject node referencing only one Safepoint node
for which it was created. And this is why there was the fix to make it pinned.
- backported by
-
JDK-2180515 SafePointScalarObject node placed into incorrect block during GCM
-
- Resolved
-
-
-
- Closed
-