[12] RFR(S) 8206963: [AOT] bug with multiple class loaders

[Vladimir Kozlov]

Thank you, Dean

Vladimir

On 10/5/18 2:33 PM, dean.long at oracle.com wrote:
> On 10/5/18 2:19 PM, Vladimir Kozlov wrote:
>> On 10/5/18 1:16 PM, dean.long at oracle.com wrote:
>>> What about the case where the AOT code has dependencies on classes that are loaded by a custom class loader?  
>>> Wouldn't we need to disable the AOT code in that case? I'm trying to come up with a test case for that.
>>
>> If method is compiled it means all referenced classes were resolved during compilation when standard builtin loaders 
>> are used. The should not be references to classes from custom class loaders. We don't have any information about 
>> custom loaders during compilation - who we can depend on them?
>>
>> Even if there is a reference for class loaded by custom class loader, with this fix corresponding got cells will not 
>> be initialized and referenced in aot methods classes will be resolved during method execution. At that time method's 
>> execution context holder class + its loader and domain will be used to find a class. And it will find one in standard 
>> classes (custom class loaders will not be searched). If it is not found runtime will throw NCFE.
>>
>> For passed argument (or static field) we should have checkcast check which should fail because the constant it is 
>> compared to will be from standard class.
>>
>> Class search for metadata (debug info) is also done using current aot method's context.
>>
>> What I am trying to say is that all runtime searches will find only standard classes or theow NCFE. We should never 
>> have got cells reference a class which is loaded by custom loader. Because of that we don't need to deoptimize.
>>
> 
> OK, the AOT code will resolve references using a system classloader.  We can assume system classloaders are well-behaved 
> and don't delegate to custom classloaders.  So there's no problem.  Your change looks good.
> 
> dl
> 
>> Thanks,
>> Vladimir
>>
>>>
>>> dl
>>>
>>>
>>> On 10/5/18 7:36 AM, Vladimir Kozlov wrote:
>>>> http://cr.openjdk.java.net/~kvn/8206963/webrev.01/
>>>> https://bugs.openjdk.java.net/browse/JDK-8206963
>>>>
>>>> After investigations and discussions I suggest that AOT should not support custom class loaders. The main issue is 
>>>> during AOT compilation we don't know anything about them and their constrains. JAOTC uses only standard builtin 
>>>> loaders.
>>>> Otherwise we would have to add class runtime checks to all field accesses and inlined code and create separate 
>>>> memory for class pointers (AOT 'got' cells) per method which may cause significant performance regression.
>>>>
>>>> I will update limitations in AOT JEP.
>>>>
>>>> Changes passed tier1-3 and Xcomp testing.
>>>>
>>>
>