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

[Paul Sandoz]

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. 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.

Paul.

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