[vector] Vector API -- alignment with value types

[Brian Goetz]

> 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.