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

[Tobias Hartmann]

Hi Tom,

this looks good to me. You might want to reference the related code in
LinkResolver::check_method_accessability in your comment(no new webrev required).

Best regards,
Tobias

On 15.01.19 08:09, 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.