While investigating a performance anomaly I discovered something weird with backedge profiling. We got a compile request where the compilation policy considered a MDO to be mature because the backedge profile counts was over 100000 but the actual profile within the MDO had only zero counts. So the interpreter was updating the backedge counters but the actual profiling logic hadn't noticed it existed. The interpreter load the MDO on entry and also when it calls profile_method but calls to the frequency_counter_overflow can also create an MDO. I made a simple fix to call set_method_data_pointer_for_bcp() after calls in the interpreter. http://hg.openjdk.java.net/graal/graal-jvmci-8/rev/ca5c97226d1c

I'm not sure it's the right fix though. I think it might be better for the code which updates MethodData::_backedge_counter to load the MDP if it notices that it's currently not set. This was the counters and the profile will always be in sync.