While getting reviews for the fix to 6303534 I noticed that the interpreters are using a
methodOop while the thread state is still thread_in_native. Since a gc can be going on
concurrently this can cause a failure. Since methodOops are in perm space they rarely
move so the bug is probably hard to observe (FullGCALot would increase the odds).
Here's a snippet of the bad code from interpreter_i486.cpp with comments added:

  // Change state to native
  __ movl(Address(thread, JavaThread::thread_state_offset()), _thread_in_native);
  __ call(eax, relocInfo::none);

  // result potentially in edx:eax or ST0
  __ get_method(method);

BUG! Can't access method here
  __ get_thread(thread);

  // Either restore the MXCSR register after returning from the JNI Call
  // or verify that it wasn't changed.
  if (VM_Version::supports_sse()) {
    if (RestoreMXCSROnJNICalls) {
      __ ldmxcsr(Address((int) StubRoutines::addr_mxcsr_std(), relocInfo::none));
    }
    else if (CheckJNICalls ) {
      __ call(CAST_FROM_FN_PTR(address, StubRoutines::i486::verify_mxcsr_entry()),
              relocInfo::runtime_call_type);
    }
  }

  // restore esi to have legal interpreter frame, i.e., bci == 0 <=> esi == code_base()
  __ movl(esi, Address(method,methodOopDesc::const_offset())); // get constMethodOop

BUG! can't access method here.

The other platforms have similar code.