This code cache lookup is useless because the method is only called from frame::deoptimize and vframeArrayElement::unpack_on_stack where pc is always part of _cb:
http://hg.openjdk.java.net/jdk/jdk/file/ee44884f3ab8/src/hotspot/cpu/x86/frame_x86.cpp#l265
If the method is called from frame::deoptimize, pc is either _cb->deopt_mh_handler_begin() or _cb->deopt_handler_begin(). Both are part of _cb:
http://hg.openjdk.java.net/jdk/jdk/file/ee44884f3ab8/src/hotspot/share/runtime/frame.cpp#l287
If the method is called from vframeArrayElement::unpack_on_stack, _frame is an interpreter frame and therefore _frame._cb is the interpreter buffer blob. pc is only set in this method and always points to an interpreter entry which should be part of the interpreter buffer blob:
http://hg.openjdk.java.net/jdk/jdk/file/ee44884f3ab8/src/hotspot/share/runtime/vframeArray.cpp#l303
http://hg.openjdk.java.net/jdk/jdk/file/ee44884f3ab8/src/hotspot/cpu/x86/frame_x86.cpp#l265
If the method is called from frame::deoptimize, pc is either _cb->deopt_mh_handler_begin() or _cb->deopt_handler_begin(). Both are part of _cb:
http://hg.openjdk.java.net/jdk/jdk/file/ee44884f3ab8/src/hotspot/share/runtime/frame.cpp#l287
If the method is called from vframeArrayElement::unpack_on_stack, _frame is an interpreter frame and therefore _frame._cb is the interpreter buffer blob. pc is only set in this method and always points to an interpreter entry which should be part of the interpreter buffer blob:
http://hg.openjdk.java.net/jdk/jdk/file/ee44884f3ab8/src/hotspot/share/runtime/vframeArray.cpp#l303