JDK-6244003 : JVM(server) freezes with -Xcomp -XX:CompileOnly=freeze.loop and -XX:-Inline in 6.0b27
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 6
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2005-03-22
  • Updated: 2012-10-08
  • Resolved: 2005-09-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
6 b51Fixed
Related Reports
Relates :  
Description
JVM (server) freezes in the following reproducible process.

CONFIGURATION :
  JRE : 6.0b27/5.0u2
  OS  : WindowsXP(SP1, Japanese)

REPRUDUCING :
  1) Compile the following test program

=== TEST PROGRAM ===>
public class freeze extends Thread {

  public static void main(String[] args) throws Exception {
    (new freeze()).start();
    Thread.sleep(1000);
    System.gc();
    System.exit(0);
  }
  public void run() {
    loop();
  }

  void loop() {
    while(true){ empty();}
  }

  void empty() {}

}

<=====================

  2) Launch the command
      "java -server -Xcomp -XX:CompileOnly=freeze.loop -XX:-Inline freeze"
     You will see the program never terminate even by CTL-C, CTL-D

###@###.### 2005-03-22 01:31:59 GMT

Comments
EVALUATION COMMENT: JPE Created The code of polling for safepoint seems deleted, This might be related to this behavior. ###@###.### 2005-03-22 01:32:00 GMT When loop() is compiled, the server compiler elides the safepoint in the while loop as it counts on safepoint polling somewhere in the called method empty(). In the test case, the interpreter never brings empty() a halt. Adding a trivial amoount of code, such as "int i = 0;" in empty() makes the problem disappear. Am reassigning the bug to the runtime group for consideration as an interpreter bug. ###@###.### 2005-03-22 23:20:47 GMT The interpreter optimizes away bytecode execution for empty methods and the interpreter entry point for them is simply a return. In order to implement this, we'd have to push an interpreter frame so that we can call InterpreterRuntime::at_safepoint(), so that the frames make sense. It defeats the recognition of empty methods. There's a call on methodOop->is_empty_method(). Wouldn't it be easier for the compilers to test this and *not* elide safepoint polls? And you could do it in platform-independant C++ code... Thanks. ###@###.### 2005-03-29 21:27:50 GMT The basic problem for the compiler is that the methodOop of the called method may not be in hand. For example, in the sample program, if the call to empty() was a true virtual, there is not a single methodOop to query. Further, if the compiler could take action at a call site based on an is_empty_method() query, class loading dependencies would have to be added; the very same as if the the callee had been inlined. Along those lines, it would be a good idea for the compiler to inline is_empty_method() methods as if they were accessors, and this would fix this bug's specific test case. But the bug remains, as it is very easy rewrite the test case to subvert the above C2 tweak. ###@###.### 2005-04-01 14:05:16 GMT
22-03-2005