Hooking up the array mismatch stub as an intrinsic in the template interpreter

[Paul Sandoz]

Hi,

I hooked up the array mismatch stub to the interpreter, with a bit of code cargo culting the CRC work and some lldb debugging [*] it appears to work and pass tests.

Can someone have a quick look to see if i am not the right track here:

  http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8151268-int-c1-mismatch/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8151268-int-c1-mismatch/webrev/>


Here are some quick numbers running using -Xint for byte[] equality:

Benchmark              (lastNEQ)   (n)  Mode  Cnt       Score      Error  Units
# Baseline
# VM options: -Xint
ByteArray.base_equals      false  1024  avgt   10  16622.453 ± 498.475  ns/op
ByteArray.base_equals       true  1024  avgt   10  16889.244 ± 439.895  ns/op

# Before patch
# VM options: -Xint -XX:-UseVectorizedMismatchIntrinsic
ByteArray.jdk_equals       false  1024  avgt   10  106436.195 ± 3657.508  ns/op
ByteArray.jdk_equals        true  1024  avgt   10  103306.001 ± 2723.130  ns/op

# After patch
# VM options: -Xint -XX:+UseVectorizedMismatchIntrinsic
ByteArray.jdk_equals       false  1024  avgt   10    448.764 ±  18.977  ns/op
ByteArray.jdk_equals        true  1024  avgt   10    448.657 ±  22.656  ns/op



The next step is to wire up C1.

Further steps would be to substitute some of intrinsics added/used for compact strings with mismatch, then evaluate the performance.

Thanks,
Paul.

[*] Stubs to be used as intrinsics in the template interpreter need to be created during the initial stage of generation, otherwise the stub address is null which leads to a SEGV that’s hard to track down.