RFR(S) 8206963: [AOT] bug with multiple class loaders
dean.long at oracle.com
dean.long at oracle.com
Fri Oct 5 21:33:11 UTC 2018
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.
>> On 10/5/18 7:36 AM, Vladimir Kozlov wrote:
>>> 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.
More information about the hotspot-compiler-dev