MH compilation is broken in valhalla(mvt branch) build

[Tobias Hartmann]

Hi,

to mitigate the impact of this, we could only bail out if the compiled lambda form really contains a value type in it's signature:

diff -r 67cdfd4b0995 src/share/vm/compiler/compileBroker.cpp
--- a/src/share/vm/compiler/compileBroker.cpp	Tue Jun 20 11:18:10 2017 +0200
+++ b/src/share/vm/compiler/compileBroker.cpp	Thu Jun 22 16:55:50 2017 +0200
@@ -1054,7 +1054,12 @@
   // value type. If compiled as root of a compilation, C2 has no way
   // to know a value type is passed.
   if (ValueTypePassFieldsAsArgs && method->is_compiled_lambda_form()) {
-    return NULL;
+    ResourceMark rm;
+    for (SignatureStream ss(method->signature()); !ss.at_return_type(); ss.next()) {
+      if (ss.type() == T_VALUETYPE) {
+        return NULL;
+      }
+    }
   }
 
   // lock, make sure that the compilation

Roland, what do you think?

I'll look into a complete fix next.

Best regards,
Tobias

On 19.06.2017 10:18, Roland Westrelin wrote:
> 
> Hi Sergey,
> 
>> I found that in valhalla build (mvt branch) MH compilation is broken if 
>> MH is stored in non-final field. Cost of MH invocation is increased 
>> ~100x times.
> 
> Compilation of lambda forms as root of compilation is currently
> disabled.
> 
> If we have a value type:
> 
> class Point {
>   double x;
>   double y;
> }
> 
> and some method is called:
> 
> foo(Point p)
> 
> when that method is JIT'ed, we use a special calling convention that
> doesn't pass a reference to p but the fields:
> 
> foo(double x, double y)
> 
> If foo is called with a method handle call and the method handle is not
> constant, foo won't be inlined in a caller, it will be called from a
> lambda form. That lambda form is specialized to the value type supertype
> so it's not aware that the value type argument is a Point. It passes a
> reference to a value type as an argument to foo but foo expects a pair
> of doubles. If the call is from an interpreted lambda form, the i2c
> takes care of loading the fields from the value type. If the call is
> from a compiled method, this would cause the compiled method foo to see
> garbage in x and y. The current workaround is to disable compilation of
> lambda forms. The correct fix I think is to have a special entry point
> in the compiled method.
> 
> That this problem is indeed the root cause of what you're seeing can be
> verified by disabling the special calling convention with:
> 
> -XX:-ValueTypePassFieldsAsArgs
> 
> Roland.
>