JVMCI may use an incorrect classloader to resolve a callee class

[Vladimir Kozlov]

CompilerRutime is used only by AOT compiled code.

The reason we disable custom classloaders (JDK-8206963) for AOT is because there are no way during 
AOT compilation to know (or even record) which class loaders will be used during execution. And 
track relations between custom class loaders is complicated for AOT code - most likely we would have 
to deoptimize all AOT code if it is used by custom class loaders.

But you are right that we need to use vframe in resolve_klass_helper() to find inlined caller which 
holder may have different class loader than root compiled method because we have several builtin 
class loaders.

Thanks,
Vladimir

On 6/14/19 5:16 AM, Doug Simon wrote:
> 
> 
>> On 14 Jun 2019, at 12:36, Tianxiao Gu <tianxiao.gu at gmail.com <mailto: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).
>>>
>>>     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). Custom classloaders have been disabled in
>>>     AOT in 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>
>>
>>
>>
>> -- 
>>
>