Hi Remi,
I am not aware of this being considered. Perhaps because the vector
specializations are generated from templates. As such I am not seeing a huge
benefit to doing this.
I admit to not understanding fully how this could work for vector arguments
with a bridge method. I can see what you are getting to avoid declaration of
co-variant overrides for simple methods such as add + lanewise, but it could
limit what JavaDoc can be referenced, for example referencing methods accepting
the primitive scalar value.
Paul.
> On Apr 20, 2020, at 7:04 AM, Remi Forax <fo...@univ-mlv.fr> wrote:
>
> BTW, did you try to add an intermediary private non visible class between
> Vector and IntVector to avoid all hand-written cast inside the implementation
> of IntVector,
> something along that line
>
> public abstract class Vector<E> {
> abstract void foo(Vector<E> vector);
> abstract Vector<E> bar();
> }
>
> /* non public */ abstract class AbstractVector<E, V extends
> AbstractVector<E, V>> extends Vector<E> {
> public abstract void foo(V vector);
> public final void foo(Vector<E> vector) { // bridge by hand
> foo((V)vector);
> }
> public abstract V bar();
> }
>
> public abstract class IntVector extends AbstractVector<Integer, IntVector> {
>
> }
>
> Rémi
>
> ----- Mail original -----
>> De: "Paul Sandoz" <paul.san...@oracle.com>
>> À: "core-libs-dev" <core-libs-dev@openjdk.java.net>, "hotspot-dev"
>> <hotspot-...@openjdk.java.net>
>> Envoyé: Jeudi 2 Avril 2020 00:46:55
>> Objet: RFR JDK-8223347 Integration of Vector API (Incubator): Java API,
>> implementation, and tests
>
>> 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/>
>>
>> (Further emails will sent for review of general HotSpot changes CPU
>> architecture
>> specific HotSpot changes, x64 and aarch64, and performance tests. For an
>> early
>> peek see the links in the description of JDK-8223347.)
>>
>> —
>>
>> The Vector API provides
>>
>> - the public Vector class with vector operations common to all supported
>> primitive types
>>
>> - public primitive specializations, such as IntVector, with common operations
>> associated with the primitive type
>>
>> - internal concrete specializations for the vector size, such as
>> Int256Vector,
>> for a vector holding 8 ints.
>>
>> Operations generally defer to one of approximately 20 vector intrinsics.
>> Some
>> operations may be composed of other operations.
>>
>> Explicit casts are performed by vector operations to ensure vectors arguments
>> are of the required shape (bit size) and element type.
>>
>> A vector intrinsic is an internal low-level vector operation. The last
>> argument
>> to the intrinsic is fall back behavior in Java, implementing the scalar
>> operation over the number of elements held by the vector. Thus, If the
>> intrinsic is not supported in C2 for the other arguments then the Java
>> implementation is executed (the Java implementation is always executed when
>> running in the interpreter or for C1).
>>
>> The public primitive specializations and the internal concrete
>> implementations
>> are generated from SSP template files, X-Vector.java.template and
>> X-VectorBits.java.template respectively.
>>
>> Overall the implementation approach is quite formulaic and rather repetitive.
>> Once you grok the pattern It should be easier to review if a little
>> laborious.
>>
>> Unit tests are auto-generated by composing templates for each operation into
>> an
>> SSP template file which is then used to generate unit test files for each
>> concrete vector class. The tests are quite extensive and have found many a
>> HotSpot issue in development across a wide range of platforms.
>>
>> Paul.
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8201271
>> <https://bugs.openjdk.java.net/browse/JDK-8201271>
