Cleaning static call stubs without cleaning the corresponding calls? (original) (raw)
Doug Simon @ Oracle doug.simon at oracle.com
Mon Nov 26 10:45:19 PST 2012
- Previous message: Report a bug in HotSpot
- Next message: RFR (M): CR 8003985: Support @Contended Annotation - JEP 142
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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();
} 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();cic->set_to_clean(); }
} if (static_call_addr != NULL) {csc->set_to_clean(); }
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/
- Previous message: Report a bug in HotSpot
- Next message: RFR (M): CR 8003985: Support @Contended Annotation - JEP 142
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]