Adding an intrinsic to the interpreter
volker.simonis at gmail.com
Mon Sep 14 13:12:09 UTC 2015
not sure if this is what you really want, but you could handle
vectorizedMismatch as an intrinsic in the interpreter which is
implemented in C++. I've done something similar when I was playing
with the ObjectLayout library a while ago (I replaced the Java method
'constructElementWithin()' with an optimized intrinsic which did some
object layout not possible in Java). The code is on GitHub:
I simply created a specialized interpreter stub for
'constructElementWithin' as a copy of native entry (see
generate_native_entry()) with simplified argument handling (because
the stub already knows its argument numbers and types).
It's a hack but not too complicated and maybe good enough for some experiments.
On Mon, Sep 14, 2015 at 12:15 PM, Paul Sandoz <paul.sandoz at oracle.com> 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?
More information about the hotspot-compiler-dev