RFR(XS) 8215748: Application fails when executed with Graal
tom.rodriguez at oracle.com
Wed Jan 16 07:00:35 UTC 2019
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.
> Best regards,
> On 15.01.19 08:09, Tom Rodriguez wrote:
>> 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.
More information about the hotspot-compiler-dev