JVMCI may use an incorrect classloader to resolve a callee class

[Doug Simon]

> On 14 Jun 2019, at 12:36, Tianxiao Gu <tianxiao.gu at gmail.com> wrote:
> 
> Hi Doug,
> 
> Thank you very much for your reply.
> 
> First, I am not sure whether the bug applies to AOT execution only. I used AOT to create the test case because in AOT I can easily force inline and also trigger the invocation of resolve_klass_by_symbol. I think this bug should apply to AOT only if method resolve_klass_by_symbol is only used by AOT.

I think that must be the case since CompilerRuntime is not present in https://github.com/graalvm/graal-jvmci-8.

> In my opinion, CompilerRutime in JVMCI should be consistent with SharedRuntime, where SharedRuntime uses the vframeStream to do the stack walk in the similar case.

Sounds reasonable but I’m not so familiar with CompilerRuntime so will others comment on that.

-Doug

> On Fri, Jun 14, 2019 at 2:35 AM Doug Simon <doug.simon at oracle.com <mailto:doug.simon at oracle.com>> wrote:
> Hi Tianxiao,
> 
> Just for clarification, this only applies to AOT execution if I understand correctly?
> 
> -Doug
> 
>> On 14 Jun 2019, at 10:09, Tianxiao Gu <tianxiao.gu at gmail.com <mailto:tianxiao.gu at gmail.com>> wrote:
>> 
>> Hi All,
>> 
>> JVMCI may use a wrong classloader to resolve a callee class when the caller frame (obtained by frame caller_frame = thread->last_frame().sender(&cbl_map);) is a compiled inlined method (see CompilerRuntime::resolve_klass_helper at http://hg.openjdk.java.net/jdk/jdk/file/1afe0cb93482/src/hotspot/share/jvmci/compilerRuntime.cpp#l60 <http://hg.openjdk.java.net/jdk/jdk/file/1afe0cb93482/src/hotspot/share/jvmci/compilerRuntime.cpp#l60>).
>> 
>> In an inlined method, the actual, direct caller of an unresolved callee may not be the root of the inline tree. The actual caller and the root of the inline tree may even have different classloaders. This should be a bug and can be reproduced with the attached test case in JDK 11. A patch would use vframeStream to walk the stack.
>> 
>> The test case is based on AOT and uses custom classloaders. In JDK 11, we are still able to use AOT with custom classloaders though it is not type-safe. (See bug report https://bugs.openjdk.java.net/browse/JDK-8206963 <https://bugs.openjdk.java.net/browse/JDK-8206963>). Custom classloaders have been disabled in AOT in http://hg.openjdk.java.net/jdk/jdk/rev/ccfa71bacd6f <http://hg.openjdk.java.net/jdk/jdk/rev/ccfa71bacd6f>. That means this bug will not be able to be reproduced in the latest JDK with the attached test case.
>> 
>> Environment:
>> $ uname -a
>> Darwin US-204496-MP.local 18.6.0 Darwin Kernel Version 18.6.0: Thu Apr 25 23:16:27 PDT 2019; root:xnu-4903.261.4~2/RELEASE_X86_64 x86_64
>> $ java -version
>> java version "11.0.2" 2019-01-15 LTS
>> Java(TM) SE Runtime Environment 18.9 (build 11.0.2+9-LTS)
>> Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.2+9-LTS, mixed mode)
>> $ jaotc --version
>> jaotc 11.0.2+9-LTS
>> 
>> 
>> Reproducing Steps:
>> 1. Unzip the attached test case and run script run.sh.
>> 2. In AOT mode, we will see a message "Should not load me!", which indicates that a wrong classloader is used.
>> 3. In interpreter mode, we will not see the message.
>> 
>> Best regards,
>> Tianxiao
>> 
>> <incorrect-caller.zip>
> 
> 
> 
> -- 
> 

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