> On 1 Apr 2020, at 23:46, Paul Sandoz <[email protected]> wrote:
>
> Hi,
>
> A prior email sent out a request for review of the Vector API in preparation
> for JEP 338: Vector API (Incubator) [1] to be proposed for target:
>
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/065345.html
> <https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/065345.html>
>
> This email expands the review of the API to the Java implementation and Java
> tests:
>
>
> http://cr.openjdk.java.net/~psandoz/panama/JDK-8223347-vector-api-integration-java/jdk_src_webrev/webrev/
>
> <http://cr.openjdk.java.net/~psandoz/panama/JDK-8223347-vector-api-integration-java/jdk_src_webrev/webrev/>
>
>
> http://cr.openjdk.java.net/~psandoz/panama/JDK-8223347-vector-api-integration-java/jdk_test_webrev/webrev/
>
> <http://cr.openjdk.java.net/~psandoz/panama/JDK-8223347-vector-api-integration-java/jdk_test_webrev/webrev/>
Overall the code seems very well structured, very repetitive (similar to any of
these implementations that are generated from templates). From what I know of
the concepts, the approach seems sound and clearly deliberate (with performance
in mind).
The API surfaces seems large at first glance (and it is), but once the reader
gets the concepts clear in their head I think it kinda works well (albeit
obviously low-level).
I’m happy to see the use of asserts in several places the code. I know that
they are not always enabled, but they are at least in our testing.
There are a bunch of FIXMEs in AbstractMask which look like they could be
(easily?) resolved, but maybe they need perf analysis before doing that?
Silly repetitive typo in the X-Vector.java template spills into several
javadocs, so I cannot resist:
* This is not a full-service named operation like
* {@link #add(Vector) add}. A masked ****version of****
* version of this operation is not directly available
* but may be obtained via the masked version of
* {@code lanewise}.
-Chris.
