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

[dean.long at oracle.com]

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.
>>>
>>