JDK-6784930 : server jvm fails with assert(!n->is_SpillCopy(),"") in -Xcomp mode with fastdebug bits
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs11
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2008-12-14
  • Updated: 2011-03-08
  • Resolved: 2011-03-08
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.
JDK 6 JDK 7 Other
6u14Fixed 7Fixed hs14Fixed
Related Reports
Relates :  
Description
server jvm fails with assertion (!n->is_SpillCopy(),"") in -Xcomp mode with fastdebug bits (both 2 and 64 bits) on all platforms.

Comments
EVALUATION The fix has been verified as part of hs15-b02 pit.
24-02-2009

SUGGESTED FIX Set minimum block frequency MIN_BLOCK_FREQUENCY 1.e-35f. Add the assert to check a block frequency.
13-01-2009

PUBLIC COMMENTS The LRG's _area value 0. is used by RA to avoid additional splits of a spill copy which has one immediately following use. But _area value 0. could be also produced if a block has frequency 0. caused by a long chain of conditional branches with small probability P <= 0.1 so that a float value underflow. As result all LRGs in such blocks have the same high score 1e35 and RA can not make progress producing a lot of spill copies. Solution: Set minimum block frequency MIN_BLOCK_FREQUENCY 1.e-35f. Add the assert to check a block frequency.
13-01-2009

EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/011517bbcd7b
13-01-2009