Cleaning static call stubs without cleaning the corresponding calls?

Doug Simon @ Oracle doug.simon at
Mon Nov 26 10:45:19 PST 2012

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...



More information about the hotspot-dev mailing list