Adding an intrinsic to the interpreter
aleksey.shipilev at oracle.com
Mon Sep 14 11:55:26 UTC 2015
Not saying we should actually care about the interpreter performance.
I would speculate the real trouble is calling multiple native getLong-s
in getLongUnaligned? If so, would re-implementing these Unsafe methods
in unsafe.cpp help performance? That will do a single native call into C
function that you want, and it seems to match your definition of
"interpreter intrinsic" below.
On 09/14/2015 01:15 PM, 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:
> This approach is designed such that one method ,
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: OpenPGP digital signature
More information about the hotspot-compiler-dev