Cleaning static call stubs without cleaning the corresponding calls?

[Doug Simon @ Oracle]

In the debug build of the Graal[1], I am seeing a hung VM caused by a thread spinning on an jump instruction that jumps to itself. Further investigation reveals this is the jump instruction in a static call stub. I can see that the stub is initialized properly in CompiledStaticCall::set_to_interpreted(). Then during a full GC, I see the stub is set to clean in nmethod::verify_metadata_loaders(). The strange thing is that the corresponding static (or opt_virtual) call is not reset at the same time. So, at some later point the static call goes to the stub which then starts spinning. Unless my diagnosis is flawed, I think the patch below fixes the problem.

diff -r 46bec43bdfc3 src/share/vm/code/nmethod.cpp
--- a/src/share/vm/code/nmethod.cpp     Wed Nov 21 23:36:06 2012 +0100
+++ b/src/share/vm/code/nmethod.cpp     Thu Nov 22 22:42:30 2012 +0100
@@ -1802,11 +1802,13 @@
      CompiledIC* cic = CompiledIC_at(iter.reloc());
      if (!cic->is_call_to_interpreted()) {
        static_call_addr = iter.addr();
+        cic->set_to_clean();
      }
    } else if (iter.type() == relocInfo::static_call_type) {
      CompiledStaticCall* csc = compiledStaticCall_at(iter.reloc());
      if (!csc->is_call_to_interpreted()) {
        static_call_addr = iter.addr();
+        csc->set_to_clean();
      }
    }
    if (static_call_addr != NULL) {

With this patch, I no longer see the hanging problem in Graal. The fact that this issue hasn't arisen for the debug builds of HotSpot makes me wonder if there is something else I'm missing...

-Doug

[1] http://openjdk.java.net/projects/graal/