[vector] Vector API -- alignment with value types

[Brian Goetz]

I thought this might be the case; zeros are so common that we may well want to just instantiate a zero vector as a species field, which can be shared.  Then we just expose “species.zero()” as a method (which ByteVector.zero() can delegate to.)  

I didn’t want to do this in my first patch because I was mostly intent on providing that we will get the same inlining with a more value-friendly API, but this makes sense to me.  

> On Feb 8, 2019, at 7:23 PM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
> 
> 
>> http://cr.openjdk.java.net/~sviswanathan/vectorIntrinsics/Brian/zero/webrev.00/
> 
> I have one comment on implementation:
> 
> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java:
> 
> +    public static ByteVector zero(ByteSpecies species) {
> +        return VectorIntrinsics.broadcastCoerced((Class<ByteVector>) species.boxType(), byte.class, species.length(),
> +                                                 0,
> +                                                 (z -> species.zero()));
> +    }
> 
> There's a slight change in behavior compared to "species.zero()" call and that's because not all arguments to VectorIntrinsics.broadcastCoerced() are guaranteed to be constant.
> 
> If JIT can't devirtualize & inline "species.boxType()", intrinsification fails and falls back to default implementation.
> 
> In case of species.zero(), a failure to inline callee leads to a virtual call, but callee contains intrinsified operation.
> 
> Overall, I believe it shouldn't matter from performance perspective right now, because a call breaks vector box elimination anyway, but in a longer term it may become important.
> 
> But I'd still prefer to see calls to VectorIntrinsics be fully specialized. In the particular case I referred to, IMO it's better to just call species.zero().
> 
> Best regards,
> Vladimir Ivanov