JDK-6519515 : Loop-opts incorrectly removed a safepoint poll from a loop with an early exit
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 5.0,5.0u12
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: linux,solaris_9,windows_xp
  • CPU: x86,sparc
  • Submitted: 2007-01-31
  • 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.
Other Other JDK 6 JDK 7 Other
5.0u16-rev,hs11Fixed 5.0u17Fixed 6u10Fixed 7Fixed hs11Fixed
Related Reports
Duplicate :  
JDK-6592429 - There is a safepoint synchronization problem with inlined natives
Duplicate :  
JDK-6566802 - Server VM hangs in 5.0u12
Relates :  
JDK-6518490 - Solaris TS scheduling class anti-starvation facility does not completely avoid starvation
Description
Safepoint incorrectly removed from loop L2
   L1: loop
    L2: loop
      safepoint
      if test goto L1
      call xx
    endloop L2
  endloop L1

See method Starve9B::Starvee in attachment.

Instructions for running:

/java/re/jdk/1.6.0/latest/binaries/solaris-sparc/bin/java -server Starve9B
 /java/re/jdk/1.5.0_10/latest/binaries/solaris-sparc/bin/java -server Starve9B

Simply run the program with no arguments.  Wait for about a minute.  It'll
report some meaningless information on stdout which you should ignore (residual
code from the program's original intended task of tracking down a solaris
scheduling issue that results in LWP starvation).  Enter CTRL-c.  The program
should hang and not exit.  You'll need to use kill -9 to get rid of it.
Another simple test case will soon be found in the j2se workspace, under:

    j2se/test/sun/security/ssl/SSLEngineImpl/SSLEngineDeadlock.java

Simply remove the Thread.yield() line in the doTask() method, and let it run in c2.  Should fail after 10-70 iterations.
Comments
SUGGESTED FIX /net/prt-archiver.sfbay/data/archived_workspaces/main/c2_baseline/2007/20070731085637.nips.bug6519515/ Webrev: http://prt-web.sfbay.sun.com/net/prt-archiver.sfbay/data/archived_workspaces/main/c2_baseline/2007/20070731085637.nips.bug6519515/workspace/webrevs/webrev-2007.07.31/index.html
31-07-2007
EVALUATION The function check_inner_safepts() marks a loop with _has_sfpt if a safepoint is found that dominates the loop's tail. This check is insufficient to ensure that the safepoint is encountered on each iteration since a loop may have multiple exits, some of which do not go through the tail. If we want to fix the bug by correcting check_inner_safepts(), C2 must check that a safepoint dominates every loop exit.
22-03-2007
EVALUATION Safepoint is removed by code in file loopnode.cpp @ line 2106 in method build_loop_early.
31-01-2007