Cleaning static call stubs without cleaning the corresponding calls?
Doug Simon @ Oracle
doug.simon at oracle.com
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...
-Doug
[1] http://openjdk.java.net/projects/graal/
More information about the hotspot-dev
mailing list