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
doug.simon at oracle.com
Tue Jul 4 09:37:40 UTC 2017
> On 4 Jul 2017, at 11:15, Claes Redestad <claes.redestad at oracle.com> wrote:
> On 2017-07-04 09:22, Doug Simon wrote:
>>>> Nit: no need for Objects.equals() for int comparisons.
>>> Doug, any reason why Objects.equals() is used?
>> At periods of development, there was no JDK9 EA build compatible with Graal. During these periods we set JVMCI9_MIN_EA_BUILD to Integer.MAX_VALUE:
>> // MAX_VALUE indicates that no current EA version is compatible with Graal.
>> // Note: Keep README.md in sync with the EA version support checked here.
>> private static final int JVMCI9_MIN_EA_BUILD = 174;
>> The code that tests JVMCI9_MIN_EA_BUILD against Integer.MAX_VALUE is effectively constant and Eclipse issues a "Dead code" warning for the "then" branch. Using Object.equals suppresses this warning. To avoid the boxing, one could refactor the test to an intsEqual helper method.
> Ok, maybe could've used a @SuppressWarnings("unused") to satisfy Eclipse,
Unfortunately the @SuppressWarnings("unused") can only be applied at the method level which is coarser grained than I'd like.
> but either way it's a branch that we shouldn't ever take.
Yes, when running on a non-EA VM, we'll never go down this path.
> I was just curious about the why, since it seemed a bit off.
Sorry - I should have put a comment in the code originally as I also had to remind myself why I did it this way ;-)
More information about the hotspot-compiler-dev