RFR: 8185858: [MVT] "must constrain OSR typestate" crash

[Tobias Hartmann]

Hi Roland,

this looks good to me. I just found and fixed these minor issues:

diff -r 1491300d343a src/share/vm/runtime/sharedRuntime.cpp
--- a/src/share/vm/runtime/sharedRuntime.cpp	Mon Aug 21 13:01:43 2017 +0200
+++ b/src/share/vm/runtime/sharedRuntime.cpp	Mon Aug 21 13:17:28 2017 +0200
@@ -2967,7 +2967,7 @@
            Handle protection_domain(THREAD, method->method_holder()->protection_domain());
            Klass* k = ss.as_klass(class_loader, protection_domain, SignatureStream::ReturnNull, THREAD);
            assert(k != NULL && !HAS_PENDING_EXCEPTION, "can't resolve klass");
-          assert(k == SystemDictionary::___Value_klass(), "other values no supported");
+          assert(k == SystemDictionary::___Value_klass(), "other values not supported");
  #endif
            bt = T_VALUETYPEPTR;
          }
diff -r 1491300d343a src/share/vm/utilities/globalDefinitions.hpp
--- a/src/share/vm/utilities/globalDefinitions.hpp	Mon Aug 21 13:01:43 2017 +0200
+++ b/src/share/vm/utilities/globalDefinitions.hpp	Mon Aug 21 13:17:28 2017 +0200
@@ -690,7 +690,7 @@
    T_NARROWKLASS_aelem_bytes = 4,
    T_VOID_aelem_bytes        = 0,
  #ifdef _LP64
-  T_VALUETYPEPTR_aelem_bytes= 4,
+  T_VALUETYPEPTR_aelem_bytes= 4
  #else
    T_VALUETYPEPTR_aelem_bytes= 8
  #endif

All tests pass. Pushed.

Thanks,
Tobias

On 09.08.2017 10:38, Roland Westrelin wrote:
> 
> http://cr.openjdk.java.net/~roland/8185858/webrev.00/
> 
> An OSR compilation with a __Value local fails because in
> Parse::load_interpreter_state():
> 
> local_type_at() returns
> TypeValueTypePtr::NOTNULL. Parse::fetch_interpreter_state() then uses
> the basic type of TypeValueTypePtr::NOTNULL to load the __Value
> local. That basic type is T_OBJECT so it loads a
> TypeInstPtr::BOTTOM. Parse::check_interpreter_type() then casts the
> result of the load to __Value. TypeInstPtr::BOTTOM and __Value are
> unrelated and the outcome of the cast causes the assert failure.
> 
> C2 handles value types either as buffered values or unbuffered values
> but we only have one basic type to designate a value type. I suggest we
> add a new one for buffered values. That also helps clean up the calling
> convention a bit.
> 
> Roland.
>