Adding an intrinsic to the interpreter

[Andrew Haley]

On 14/09/15 11:15, Paul Sandoz wrote:
> 
> 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?

It's important to note that good performance of getLongUnaligned (on a
machine which does not support unaligned accesses) depends on accurate
profile data.  If we're not using tiered compilation we'll hit C2 with
no profile data at all.  Whatever else you do, please make sure that
we don't break C2 performance in such circumstances.

Andrew.