[9] RFR(S) 8183401: compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/NativeCallTest.java fails with The VM does not support the minimum JVMCI API version requ

[Vladimir Kozlov]

On 7/3/17 3:39 PM, Claes Redestad wrote:
> Looks reasonable for 9 (assuming there is some compatibility story 
> preventing you from using Runtime.version() and friends?).

This is Graal code which work with JDK 8 too where this new API is not 
available. Even so JDK 9 has only copy of Oracle Lab's Graal we want to 
keep them similar.

> 
> Nit: no need for Objects.equals() for int comparisons.

Doug, any reason why Objects.equals() is used?

Thanks,
Vladimir

> 
> Thanks!
> 
> /Claes
> 
> On 2017-07-03 23:45, Vladimir Kozlov wrote:
>> This is fix for P1 in JDK 9.
>>
>> https://bugs.openjdk.java.net/browse/JDK-8183401
>> webrev:
>> http://cr.openjdk.java.net/~kvn/8183401/webrev/
>>
>> Contribute by Doug Simon.
>>
>> After JDK 9 version string changed from "9-ea+174" to "9+176" Graal 
>> stop working because it does not recognize this version string. It 
>> looked for "9-ea". As result AOT does not work and all AOT [1] and 
>> JVMCI tests fail.
>>
>> The same problem also exists in JDK 10 but we did not hit it yet 
>> because we did not test AOT in *promoted* builds yet. Our current jdk 
>> 10 builds (from JPRT) have "internal" in version string and Graal's 
>> version check accepts it.
>>
>> The fix changed jdk 9 version check to "9+" and removed failure exit 
>> for other versions including 10:
>>
>> +      } else {
>> +          // Graal will be compatible with all JDK versions as of 9 GA
>> +          // until a JVMCI API change is made in a 9u or later release.
>>
>>
>> And the code is updated (added try{}) to match one in JDK 10 [2].
>>
>> Thanks,
>> Vladimir
>>
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8183403
>> [2] 
>> http://hg.openjdk.java.net/jdk10/hs/hotspot/file/7b76d42c6419/src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/JVMCIVersionCheck.java 
>>
>