[vector] simple clean ups

[Paul Sandoz]

Hi,

I have returned… and to get back into the swing of things here is a simple cleanup of vector doc and source:

  http://cr.openjdk.java.net/~psandoz/panama/vector-cleanups/webrev/ <http://cr.openjdk.java.net/~psandoz/panama/vector-cleanups/webrev/>

The doc changes do not impact the in-progress CSR.  Some of the changes are to remove trailing white space to ensure jcheck passes (I did not exhaustively do this, just for files impacted by other changes).

—

Observations:

- the API is the same and yet not the same :-) the overall design has not changed but there has been some good compression of operations and better abstractions around conversion, the slice is a nice abstraction from which shift/rotate elements can be expressed without resorting to a shuffle.

- the shuffleTest is failing for certain vectors on my Mac [*] (regardless of my change set).  Is this a known issue?

- the JavaDoc for mask accepting fromByteBuffer makes reference to itself rather than be specified similarly to toByteBuffer (I will fix that in another change set)

/**
 * Loads a vector from a {@linkplain ByteBuffer byte buffer}
 * starting at an offset into the byte buffer
 * and using a mask.
 ..
 * This method behaves as if it returns the result of calling
 * {@link #fromByteBuffer(VectorSpecies,ByteBuffer,int,ByteOrder,VectorMask)
 * fromByteBuffer()} as follows:
 * <pre>{@code
 * var bb = ByteBuffer.wrap(a);
 * var bo = ByteOrder.LITTLE_ENDIAN;
 * var m = species.maskAll(true);
 * return fromByteBuffer(species, bb, offset, m, bo);
 * }</pre>
…
*/
IntVector fromByteBuffer(VectorSpecies<Integer> species,
                                    ByteBuffer bb, int offset,
                                    ByteOrder bo,
                                    VectorMask<Integer> m) {


- VectorMask specifies a cross-lane reduction operations but makes not reference to it, we could do so for anyTrue, allTrue, and trueCount.


- the random operation is over specified to depend on the PRNG of ThreadLocalRandom, while that PRNG is unspecified I think we should unlink the two (same PRNG and current thread) and present the use of ThreadLocalRandom as one possible implementation.

Paul.

[*]
jdk/incubator/vector/Double256VectorTests.java:
jdk/incubator/vector/DoubleMaxVectorTests.java:
jdk/incubator/vector/Float128VectorTests.java:
jdk/incubator/vector/Float256VectorTests.java:
jdk/incubator/vector/FloatMaxVectorTests.java:
jdk/incubator/vector/Int128VectorTests.java:
jdk/incubator/vector/Long256VectorTests.java:
jdk/incubator/vector/LongMaxVectorTests.java:
jdk/incubator/vector/Short128VectorTests.java:
jdk/incubator/vector/Short64VectorTests.java:


test Double256VectorTests.shuffleTest(): failure
java.lang.AssertionError: expected [[2.121995791E-314, 6.365987374E-314, 1.0609978957E-313, 1.48539705397E-313]] but found [[0.0, 1.0, 2.0, 3.0]]
	at org.testng.Assert.fail(Assert.java:94)
	at org.testng.Assert.failNotEquals(Assert.java:496)
	at org.testng.Assert.assertEquals(Assert.java:125)
	at org.testng.Assert.assertEquals(Assert.java:167)
	at Double256VectorTests.iotaShuffle(Double256VectorTests.java:758)
	at Double256VectorTests.shuffleTest(Double256VectorTests.java:766)