[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