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

[Vladimir Kozlov]

Hi Andrew,

Yes, it could be done. But in what cost.

Currently AOT shares class pointers (got cells) for all methods in AOT library. It was intentional to improve 
performance and it is okay with "well behave" class loaders. To support custom class loaders, as you said, we would have 
to keep them separate per method (or per method's holder) and resolve them in each method. Also we would have to add 
checks for not only static fields accesses (as we do now) but regular fields as well. And we need classes checks before 
all inlined code. That is what we found and we may missed something. Based on this I prefer to support only most common 
cases when custom class loaders are not used.

We also compare class fingerprints but it is not enough (we don't record path and may be other things).

Thanks,
Vladimir

On 10/6/18 2:24 AM, Andrew Haley wrote:
> On 10/05/2018 03:36 PM, 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.
> 
> For interest, we did get this working correctly in GCJ, regardless of
> class loader.  We used a cryptographic hash of the entire class file
> to look up the correct compiled code and then resolved the references
> from the code using the usual JVM rules. This is always correct, I
> think.
>