[12] RFR(XS) 8215748: Application fails when executed with Graal
Tom Rodriguez
tom.rodriguez at oracle.com
Tue Jan 15 07:09:12 UTC 2019
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