[10] (S) RFR 8184361: AOT lib at jdk/lib/libjava.base-coop.so seems to override -XX:AOTLibrary=

Vladimir Kozlov vladimir.kozlov at oracle.com
Wed Nov 29 02:38:21 UTC 2017


Thank you, Dean

On 11/28/17 6:19 PM, dean.long at oracle.com wrote:
> On 11/28/17 5:55 PM, Vladimir Kozlov wrote:
> 
>> http://cr.openjdk.java.net/~kvn/8184361/webrev.00/
>> https://bugs.openjdk.java.net/browse/JDK-8184361
>>
>> Change priority in which AOT libraries are loaded.
>>
>> First, load libraries specified by AOTLibrary. And then, well known libraries from JAVA 
>> installation directory. Don't load a library if an other library with the same name is already 
>> loaded.
>>
>> It will allow do quick experiments with modified libraries.
>>
>> Manual testing and AOT jtreg tests.
>>
>> Thanks,
>> Vladimir
> 
> It looks OK, but it imposes an undocumented? naming convention that must be followed.  If have use 
> dir1/foo.so and dir2/foo.so, then only first will get loaded, so I need to use unique file names.  
> And if I (accidentally) name it lib<module>.so, then the system version won't get loaded, so users 
> must know the naming convention to avoid conflicts.  If users need to following a naming convention 
> to avoid conflicts, then it might make sense to deprecate AOTLibrary and instead have something more 
> convenient for multiple libraries, like a AOTLibraryPath search path option.

Yes, you should use different names if you are loading AOT libraries with different classes.
Allowing to load libraries with the same name was oversight. It cause at least one bug JDK-8167526 
which you fixed.

Search path has the same problem, I think. You don't know what will be loaded first.

Names of well-known AOT libraries are documented in AOT JEP just before "Steps to generate and use 
an AOT library for the java.base module" section:

http://openjdk.java.net/jeps/295

> 
> I wonder if we should always print the warning, instead of putting it under PrintAOT.

This is what we do in other cases with AOT - most AOT messages are under PrintAOT.

Thanks,
Vladimir

> 
> dl


More information about the hotspot-compiler-dev mailing list