Adding an intrinsic to the interpreter

John Rose john.r.rose at
Tue Sep 15 04:42:39 UTC 2015

On Sep 14, 2015, at 11:35 AM, Paul Sandoz <paul.sandoz at> wrote:
> 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.

I agree this is worth a first try.  Try to intrinsify the smaller bits first.
The interpreter has math intrinsics (AbstractInterpreter::java_lang_math_sqrt / vmIntrinsics::_dsqrt)
The enum in AbsInterp predates the vmIntrinsics enum, and there is duplication between them.

If we add new special cases to AbstractInterpreter, they might just vector through the Method::_intrinsic_id slot to a leaf C function.
(Perhaps different distinct leaf-function signatures get distinct MethodKind values.)
The extra indirections (via a function pointer table indexed by intrinsic_id) are noise in the interpreter.
The existing hardwired math functions could (in principle) be treated this way, as an additional cleanup.

— John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the hotspot-compiler-dev mailing list