Adding an intrinsic to the interpreter

[Paul Sandoz]

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.

Paul.

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:
> 
> https://jbs.oracle.com/bugs/browse/JDK-7088419
> https://jbs.oracle.com/bugs/browse/JDK-8134553
> 
> http://cr.openjdk.java.net/~drchase/7088419/webrev.06/
> http://cr.openjdk.java.net/~mcberg/8134553/webrev.02/
> 
> Regards,
> Vladimir

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:
> 
> https://github.com/simonis/ObjectLayout/blob/hotspot_intrinsification/hotspot/mq/patches/ObjectLayout_intrinsify_constructElementWithin.patch
> 
> 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.
> 
> Regards,
> Volker
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20150914/b53e04bd/signature.asc>