Vector API using MemorySegment <was> Re: Separation between MemorySegment and MemoryScope

[forax at univ-mlv.fr]

----- Mail original -----
> De: "Paul Sandoz" <paul.sandoz at oracle.com>
> À: "Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>
> Cc: "Remi Forax" <forax at univ-mlv.fr>, "panama-dev at openjdk.java.net'" <panama-dev at openjdk.java.net>
> Envoyé: Lundi 29 Mars 2021 21:37:33
> Objet: Vector API using MemorySegment <was> Re: Separation between MemorySegment and MemoryScope

> Yeah, sounds messy, would prefer to enhance the Vector API to use MemorySegment
> when Panama exits incubation (and/or preview).
> 
> Regarding bounds checks: Remi, you may have noticed we have a system property to
> disable them [1] for vector load/stores from arrays and buffers, but this is
> really just for performance investigation. 

yes, i've noticed that but I don't care about most of the bound checks but the one that are in tight loops closed to vectorized operations, because those bounds checks appears on the profiler and are causing a 2x to 3x slowdown when the vectorized loop is very simple (moving/copying primitive values around).

> I consider it a bug if HotSpot could
> but does not strength reduce ‘em and remove ‘em from a loop body (although C2
> does have some limitations that are hard to overcome). I would be reluctant to
> add a supported feature to MemoryScope to remove bounds checks on access.

So you can log a bug because bounds checks are removed by c2 when using the *Vector.fromArray but not using *Vector.fromByteBuffer,
c2 doesn't care to try to prove that an index is always between [0 .. buffer.capacity) (see [1])

Also having the ByteBuffer to be a constant doesn't lead to a better code too,
the generated assembly code still use a register to access to the address of the underlying buffer instead of using directly to the address which is a constant.

I can see both those optimizations on primitive arrays but not on ByteBuffer, which is kind a shame because the only way to currently access a MemorySegment from the Vector API is through a ByteBuffer.

> 
> Paul.

Rémi

[1] https://github.com/forax/tomahawk/blob/master/src/main/java/com/github/forax/tomahawk/perf/VecOpPerfTest.java#L105

> 
> static final int VECTOR_ACCESS_OOB_CHECK =
> Integer.getInteger("jdk.incubator.vector.VECTOR_ACCESS_OOB_CHECK", 2);
> …
> 
> @ForceInline
> static int checkFromIndexSize(int ix, int vlen, int length) {
>    switch (VectorIntrinsics.VECTOR_ACCESS_OOB_CHECK) {
>        case 0: return ix; // no range check
>        case 1: return Objects.checkFromIndexSize(ix, vlen, length);
>        case 2: return Objects.checkIndex(ix, length - (vlen - 1));
>        default: throw new InternalError();
>    }
> }
> 
>> On Mar 26, 2021, at 5:33 PM, Maurizio Cimadamore
>> <Maurizio.Cimadamore at Oracle.COM> wrote:
>> 
>> I'll let Paul comment on this.
>> 
>> I buy there's _some_ way to make it work, but boy, it ain't pretty ;-)
>> 
>> Maurizio
>> 
>> On 26/03/2021 23:28, forax at univ-mlv.fr wrote:
>>> ----- Mail original -----
>>>> De: "Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>
>>>> À: "Remi Forax" <forax at univ-mlv.fr>, "panama-dev at openjdk.java.net'"
>>>> <panama-dev at openjdk.java.net>
>>>> Envoyé: Vendredi 26 Mars 2021 23:52:19
>>>> Objet: Re: Separation between MemorySegment and MemoryScope
>>> Let's separate the issues,
>>> 
>>> [...]
>>> 
>>>> Elsewhere Paul said that Vector will look at
>>>> integration with MemorySegment, but can only do so after MemorySegment
>>>> lands in java.base (aaaah these incubating modules).
>>> This is how it can be done.
>>> Notice that we want jdk.incubator.vector to access classes of
>>> jdk.incubator.foreign so it not really an issue, the issue is if java.base want
>>> to access to an incubator module because a module can not be a parent (every
>>> modules as java.base as parent) and a child (java.base requiring
>>> jdk.incubator.*) at the same time, there is a no cycle rule in the Java module
>>> spec.
>>> 
>>> The problem is more that we may don't want jdk.incubator.vector to depend on
>>> jdk.incubator.foreign, users may want one module but not the other.
>>> Again there is a solution for that, doing a "requires static", the module has to
>>> be there at compile time, but not at runtime.
>>> 
>>> We still have an issue if we have a method that is part of the public API of of
>>> jdk.incubator.vector that uses MemorySegment, but typing the method parameter
>>> has Object instead of MemorySegment will work,
>>> (Note, this is not really a big issue because class are loaded dynamically and
>>> javac will only emit a warning, i believe, but if someone use the Vector API by
>>> reflection, it may fail)
>>> i.e. the classes jdk.incubator.vector can use the class of jdk.incubator.vector
>>> if it's only part of the private API.
>>> You also have to add the module by hand in the module graph because the
>>> initialization of the module graph do not follow the "requires static" branch
>>> but given that it's an incubator module,
>>> you have to add it by hand anyway.
>>> 
>>>> Cheers
>>>> Maurizio
> >> Rémi