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

[Vladimir Kozlov]

Looks good.

Thanks,
Vladimir

On 1/14/19 11:09 PM, Tom Rodriguez 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.