[12] RFR(XS) 8215748: Application fails when executed with Graal

[Igor Veresov]

Looks good.

Igor

> On Jan 14, 2019, at 11:09 PM, Tom Rodriguez <tom.rodriguez at oracle.com> wrote:
> 
> http://cr.openjdk.java.net/~never/8215748/webrev
> https://bugs.openjdk.java.net/browse/JDK-8215748
> 
> If an interface method attempts to invoke an array clone method, JVMCI doesn't let you resolve the invoke properly which can result in performance problems or unexpected NullPointerExceptions.  clone is publicly visible on arrays but is protected in Object.  HotSpot doesn't have an actual Method* for the array clone operations, it just reuses Object.clone.  This is accomplished with some trickery in the linkResolver.cpp that adjusts the visibility during resolution if an array class is involved.  JVMCI only deals with concrete methods so when a call site is resolved you get back the real Object.clone.  If you try to use resolveMethod on it then it will resolve it relative to Object instead of using the array type.  This works ok when the accessing class is an class but for interface types it fails.  In benign cases Graal just ends up falling back to a regular call which is slower than normal.  In this case we were attempting to resolve an invoke for a profiled call site and got back null which shouldn't happen.  The fix is the use the array class as the method type in this particular case which mirrors the logic in the linkResolver.cpp that adjusts the visibility check. Tested with Spark and the new unit test.  mach5 testing is ongoing.