During work on JDK-8223531 Tom R. said:

In jdk8 the int_at call is guarded by this:

      if (locals->at(_index)->type() == T_CONFLICT) {
        memset(&_value, 0, sizeof(_value));
        _value.l = NULL;
        return;
      }

This was rearranged in more recent JDKs by JDK-8080406. It looks like after that change it should be returning JVMTI_ERROR_INVALID_SLOT for the T_CONFLICT case which is good. I think the problem is that VM_GetOrSetLocal::check_slot_type_lvt doesn't include a check of the actual local type like check_slot_type_no_lvt does. It sure seems like check_slot_type_no_lvt should always be run, even if you have an lvt. Maybe something like this:

diff -r 1dbe0c210134 src/hotspot/share/prims/jvmtiImpl.cpp
--- a/src/hotspot/share/prims/jvmtiImpl.cpp
+++ b/src/hotspot/share/prims/jvmtiImpl.cpp
@@ -748,10 +748,11 @@
     }
   }
 
+ if (!check_slot_type_no_lvt(_jvf)) {
+ return false;
+ }
   if (method_oop->has_localvariable_table()) {
     return check_slot_type_lvt(_jvf);
- } else {
- return check_slot_type_no_lvt(_jvf);
   }
   return true;
 }

I presume the test case would have failed in that case even in product mode because of the error return. But we'd need [~sspitsyn] to comment on the intent of those two methods.