[10] RFR(S) 8181823: [AOT] jaotc doesn't work with Graal

dean.long at oracle.com dean.long at oracle.com
Wed Jun 21 21:28:35 UTC 2017


That makes me wonder if jaotc uses of CalculateClassFingerprint and 
UseAOT should be replaced by a single flag, like UseJAOTCCompiler.  I 
don't see why we need enable all of the UseAOT and #if INCLUDE_AOT logic 
for jaotc.  In my opinion they could be separated, but we can do it later.

dl


On 6/21/17 2:12 PM, Vladimir Kozlov wrote:
> Yes. We switch off UseAOT if it is default (not on command line) and 
> no AOT library is present.
> But we need it fot jaotc. There is fingerprint code which guarded by 
> UseAOT.
> Also it is used in jvmci when jaotc ask for method's metadata:
>
> http://hg.openjdk.java.net/jdk10/hs/hotspot/file/f20fd31ad61f/src/share/vm/jvmci/jvmciCodeInstaller.cpp#l718 
>
>
> Vladimir
>
> On 6/21/17 1:17 PM, dean.long at oracle.com wrote:
>> This is not directly related to your change, but does jaotc need an 
>> explicit -XX:+UseAOT?
>>
>> dl
>>
>>
>> On 6/20/17 7:29 PM, Vladimir Kozlov wrote:
>>> https://bugs.openjdk.java.net/browse/JDK-8181823
>>> webrev:  http://cr.openjdk.java.net/~kvn/8181823
>>>
>>> Original condition to calculate class fingerprint during AOT 
>>> compilation (when run jaotc) does not work if Graal used as JIT 
>>> compiler.
>>> New product flag CalculateClassFingerprint is added to specify when 
>>> calculate class fingerprint. Pass it to VM from jaotc launcher.
>>>
>>>
>>> Fixes in Graal's module-info.java and java.cpp were done to be able 
>>> run JTREG with Graal in jdk10/hs. Otherwise I got missing HandleMark 
>>> error and ServiceConfigurationError:
>>>   java.util.ServiceConfigurationError: 
>>> org.graalvm.compiler.hotspot.HotSpotCodeCacheListener: module 
>>> jdk.internal.vm.compiler does not declare `uses`
>>>
>>> Thanks,
>>> Vladimir
>>



More information about the hotspot-compiler-dev mailing list