Adding an intrinsic to the interpreter

[Paul Sandoz]

On 15 Sep 2015, at 10:46, Andrew Haley <aph at redhat.com> wrote:

> 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.
> 

Thanks for pointing that out, a good argument for focusing on the aligned accessors.

Paul.