RFR 8152903: [JVMCI] CompilerToVM::resolveMethod should correctly handle private methods in interfaces

Igor Veresov igor.veresov at oracle.com
Thu Apr 28 02:43:30 UTC 2016


Good.

igor

> On Apr 27, 2016, at 4:51 PM, Tom Rodriguez <tom.rodriguez at oracle.com> wrote:
> 
> One of the jtreg tests had to be fixed after these changes, so I’ve updated the webrev.  The only changed file is http://cr.openjdk.java.net/~never/8152903/webrev/test/compiler/jvmci/compilerToVM/ResolveMethodTest.java.udiff.html <http://cr.openjdk.java.net/~never/8152903/webrev/test/compiler/jvmci/compilerToVM/ResolveMethodTest.java.udiff.html>
> 
> The test case was actually resolving the method against the holder type instead of the receiver but this only mattered for interface types.  We also require the type to be linked before answering the question so we have to force initialization.  
> 
> tom
> 
>> On Apr 21, 2016, at 8:23 PM, Igor Veresov <igor.veresov at oracle.com <mailto:igor.veresov at oracle.com>> wrote:
>> 
>> Looks good!
>> 
>> igor
>> 
>>> On Apr 21, 2016, at 6:22 PM, Tom Rodriguez <tom.rodriguez at oracle.com <mailto:tom.rodriguez at oracle.com>> wrote:
>>> 
>>> http://cr.openjdk.java.net/~never/8152903/webrev <http://cr.openjdk.java.net/~never/8152903/webrev> 
>>> 
>>> JVMCI had it own custom version of the resolution logic when it should be doing something similar to what ciMethod::resolve_invoke is doing. This required a semantic change that if the type is an interface no meaningful answer can be provided. I updated tests and the interface a little to reflect this. 
>>> 
>>> Making this change exposed a problem with -Xcomp where the resolution by the compiler was triggering compilation instead of the first real invoke. I rearranged the code a little for this to ensure that code wasn't executed for the Compiler thread. It passes the graal gate with these changes.  A modified version of the test which found the issue also passes now.  I filed a bug suggesting changes to that test that would make it work better with compiler like C2 and Graal that don’t handle unloaded classes.  https://bugs.openjdk.java.net/browse/JDK-8154904 <https://bugs.openjdk.java.net/browse/JDK-8154904>
>>> 
>>> tom
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20160427/c3966b57/attachment.html>


More information about the hotspot-compiler-dev mailing list