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

[Vladimir Kozlov]

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.

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