[vector] Vector API -- alignment with value types

[Viswanathan, Sandhya]

Hi Brian,

Thanks, we will try to do as much as possible based on the direction that we have received from you in next two weeks and then we can go from there.

Best Regards,
Sandhya


From: Brian Goetz [mailto:brian.goetz at oracle.com]
Sent: Thursday, January 31, 2019 5:55 PM
To: Viswanathan, Sandhya <sandhya.viswanathan at intel.com>; panama-dev at openjdk.java.net
Subject: Re: [vector] Vector API -- alignment with value types



Your patch only had the fromByteArray flavor of the factory method as part of the XXXVector class.

Right.  I had migrated about half the methods from XxxSpecies to XxxVector (and meanwhile, Kishore migrated a few more), but there was no real order to the choice other than "start at the top, and proceed until I had to get on a plane."

I presume what you did was to use the same technique -- migrate instance methods on the XxxNnVector.Species class to static methods on the XxxVector class, and adjust appropriately.



To compile and execute the above I needed to add the fromArray factory method to the FloatVector class.

Adding that on similar lines as the fromByteArray method to FloatVector.java:

    @ForceInline

    @SuppressWarnings("unchecked")

    public static FloatVector fromArray(FloatSpecies species, float[] a, int ix) {

        Objects.requireNonNull(a);

        ix = VectorIntrinsics.checkIndex(ix, a.length, species.length());

        return VectorIntrinsics.load((Class<FloatVector>) species.boxType(), float.class, species.length(),

                                     a, (((long) ix) << ARRAY_SHIFT) + Unsafe.ARRAY_FLOAT_BASE_OFFSET,

                                     a, ix,

                                     (c, idx) -> species.op(n -> c[idx + n]));

    }

This looks like it follows the pattern.





With this change, when I execute the test kernel as below:

$JAVA_HOME/bin/java --add-modules=jdk.incubator.vector  -XX:CompileCommand=print,mytest.workload  -XX:CompileCommand=dontinline,mytest.workload   -Djdk.incubator.vector.VECTOR_ACCESS_OOB_CHECK=0 -XX:-UseSuperWord -XX:+PrintInlining mytest >& out



All the load/store and binaryOp intrinsics continue to happen:

That's very encouraging!  Seems like this makes it worth pursuing doing this transform in a more orderly and careful way (mine was neither.)  If this pans out, then we can collapse the species abstraction to a simple data carrier.  It doesn't reduce the surface of the API by much (even increases it a bit, if we add the overloads that don't take species, and just default to the preferred species) but it reduces the learning curve and the implementation size, and lines us up to make Species into values.

When we convert AbstractSpecies into an interface, I suspect we'll see some (temporary) compilation regressions.


When we finish this round, we can take a swing at doing the same for rolling up the Vector implementations.

I'm traveling for the next two weeks but can return to this when I get back.