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

[Tom Rodriguez]

Tobias Hartmann wrote on 1/15/19 2:32 AM:
> 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).

Good suggestion.  I added a mention of that at the end of the comment. 
Thanks!

tom

> 
> 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.