JDK-6809798 : SafePointScalarObject node placed into incorrect block during GCM
- Type: Bug
- Component: hotspot
- Sub-Component: compiler
- Affected Version: hs14
- Priority: P4
- Status: Resolved
- Resolution: Fixed
- OS: generic
- CPU: generic
- Submitted: 2009-02-25
- Updated: 2010-04-03
- Resolved: 2009-03-18
The Version table provides details related to the release that this issue/RFE will be addressed.
Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
To download the current JDK release, click here.
Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
To download the current JDK release, click here.
| JDK 6 | JDK 7 | Other |
|---|---|---|
6u18Fixed  |
7Fixed |
hs15Fixed |
Description
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.
Comments
|