Adding an intrinsic to the interpreter
paul.sandoz at oracle.com
Mon Sep 14 15:35:07 UTC 2015
Hi Volker, Vladimir
Thanks. Those patches provides a useful guide of changes required. If I take the plunge I would prefer to tackle getLong, as a quicker hack, rather than vectorizedMismatch in terms of the generated machine code.
On 14 Sep 2015, at 17:30, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> Hi Paul,
> Look how crc32/crc32c are implemented, they create stubs which are called from Interpreter and JITed code:
On 14 Sep 2015, at 15:12, Volker Simonis <volker.simonis at gmail.com> wrote:
> Hi Paul,
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the hotspot-compiler-dev