Adding an intrinsic to the interpreter

[Vladimir Kozlov]

Hi Paul,

Look how crc32/crc32c are implemented, they create stubs which are called from Interpreter and JITed code:

https://jbs.oracle.com/bugs/browse/JDK-7088419
https://jbs.oracle.com/bugs/browse/JDK-8134553

http://cr.openjdk.java.net/~drchase/7088419/webrev.06/
http://cr.openjdk.java.net/~mcberg/8134553/webrev.02/

Regards,
Vladimir

On 9/14/15 3:15 AM, Paul Sandoz wrote:
> Hi,
>
> Any pointers/guidance for adding an intrinsic to the interpreter would be much appreciated. Initially a quick hack might be sufficient for verification purposes.
>
> The context is adding array comparison and mismatch methods:
>
>    http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8033148-Arrays-lexico-compare/webrev/
>
> This approach is designed such that one method [1], vectorizedMismatch, can be made intrinsic in C2 (e.g. to leverage AVX instructions on x86) and then other functionality is built on top of that. That method utilises Unsafe.getLongUnaligned to view array components as long values.
>
> When run in the interpreter a modified Array.equals can be 3x to 20x slower than the unmodified version (depending on the array component type). Some slow down is acceptable but perhaps not quite that much. I suspect that is due to the overhead of making a native call to Unsafe.getLong which is wrapped in Unsafe.getLongUnaligned.
>
> How difficult would it be to add an interpreter intrinsic supporting getLong/Unaligned? perhaps it does not need to be asm-based if one can defer to a C++ function e.g. somehow wire up to bytes.cpp functionality for the address of base + offset?
>
> Thanks,
> Paul.
>
> [1]
> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8033148-Arrays-lexico-compare/webrev/src/java.base/share/classes/java/util/ArraysSupport.java.html
>