[12] RFR(XS) 8215748: Application fails when executed with Graal
Vladimir Kozlov
vladimir.kozlov at oracle.com
Tue Jan 15 18:31:05 UTC 2019
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.
More information about the hotspot-compiler-dev
mailing list