Vector Intrinsics & Boxing Problems?

[August Nagro]

Hello,

I've been playing around with the vector api, and am trying to debug
some performance problems.

I'm on Linux x86, and it seems like some of the ops on ByteVector128
are not being intrinsified. When I print the assembly with
-XX:+PrintAssembly, I noticed that the ymm registers are not being
used much / were close together. After -XX:+PrintIntrinsics I can see
that there are some failures among the successes:

@ 245   jdk.internal.vm.vector.VectorSupport::binaryOp (36 bytes)
failed to inline (intrinsic)

@ 52   jdk.internal.vm.vector.VectorSupport::compare (40 bytes) failed
to inline (intrinsic)

** missing constant: vclass=ConP etype=ConP vlen=ConI idx=Parm
                              @ 16
jdk.internal.vm.vector.VectorSupport::extract (35 bytes)   failed to
inline (intrinsic)

** missing constant: opr=RShiftI vclass=ConP etype=ConP vlen=ConI
                                  @ 106   java.lang.Object::getClass
(0 bytes)   (intrinsic)
                                  @ 134
jdk.internal.vm.vector.VectorSupport::broadcastInt (36 bytes)   failed
to inline (intrinsic)


Here is one hot code that may be a problem:
byteVector128.test(IS_NEGATIVE). Inspecting the source, I see an
IS_NEGATIVE test is passed to ByteVector::testTemplate, which calls
`bits.compare(LT, 0)`. Eventually it reaches the intensified
VectorSupport::compare.

I have never looked at hotspot intrinsic code before so bear with me.
In vmIntrinsics.hpp, _VectorCompare is the name of the template. I
don't understand where to go from here. However, I did notice file
share/prims/vectorSupport.hpp, which is missing the BT_lt and other
comparison constants in VectorSupport.java.

Am I on the right path here? And finally, is there a way to tell if
Vector boxing is occurring?

Regards,

August