What we have lost ?

[forax at univ-mlv.fr]

----- Original Message -----
> From: "Paul Sandoz" <paul.sandoz at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Brian Goetz" <brian.goetz at oracle.com>, "valhalla-spec-experts" <valhalla-spec-experts at openjdk.java.net>
> Sent: Monday, September 12, 2022 7:31:09 PM
> Subject: Re: What we have lost ?

> Part of the exploration that I omitted in my prior email is to enhance C2s
> calling convention to support vector arguments, thereby enabling the passing of
> vector arguments as vector registers.
> (This might also shed some light on how we might support Panama native calls
> too.)
> 
> The constant species might come along for the ride as a side-argument with the
> “bag of bits” e.g. an ad-hoc form of specialization. Hard to say exactly until
> we experiment.

I want the VM to speculate on the type argument of a raw type / wildcard, so there is no need to pass the argument as a parameter.

Obviously, it's harder that speculating on the implementation of a virtual method but a wildcard is a kind of virtual representation of several parametrized generics classes.

If a method like foo() is not inlined 

  static final VectorSpecies SPECIES = IntVector.SPECIES_128;

  IntVector foo() {
    return IntVector.broadcast(SPECIES, 42);
  }

the VM can still know that the real return type is IntVector<SPECIES_128>.

If not in the case of the Vector API where we want to hide the Species, a generic method is enough because it will be specialized, so i'm not sure there is a need to pass a type argument as an argument on the stack.

> 
> Paul.
> 

Rémi

> 
>> On Sep 11, 2022, at 7:04 AM, forax at univ-mlv.fr wrote:
>> 
>> ----- Original Message -----
>>> From: "Paul Sandoz" <paul.sandoz at oracle.com>
>>> To: "Remi Forax" <forax at univ-mlv.fr>
>>> Cc: "Brian Goetz" <brian.goetz at oracle.com>, "valhalla-spec-experts"
>>> <valhalla-spec-experts at openjdk.java.net>
>>> Sent: Thursday, September 8, 2022 1:10:26 AM
>>> Subject: Re: What we have lost ?
>> 
>>> The Vector API is I think a proof point that ref projection can be acceptable
>>> and can work.
>>> 
>>> The Vector API implementation currently behaves approximately as if a vector
>>> instance (whose concrete class is private) is a ref to a value object. The C2
>>> compiler performs aggressive unboxing and mapping "payloads" (analogous to
>>> value objects) vectors hold to vector registers, rather than scalarizing the
>>> element “overlay” or view over the payload described by the vector’s shape and
>>> element type (the species).
>>> 
>>> In this current model we generally don’t recommend storing vector instances in
>>> the heap (there are exceptions to that rule for constants), and instead vectors
>>> are loaded from or stored to memory containers such as arrays, byte buffers, or
>>> memory segments. After a few iterations of the API and implementation its
>>> starting to work rather well at generating efficient vectorized code on
>>> supporting hardware.
>>> 
>>> 
>>> We are currently early in the process of exploring alignment of the Vector API
>>> with Valhalla where:
>>> 
>>> 1. the private concrete vector classes are value classes whose .val type is
>>> private; and
>>> 2. a vector value class has a "payload" field whose type is a value type.
>>> 
>>> The "payload" is a non-atomic "bag of bits" e.g. values types of Bits256.val,
>>> Bits128.val etc, which would not be exposed in the public Vector API. So no
>>> utterance of .val is expected in this model. The API remains the same as it
>>> does today.
>>> 
>>> We could decide the value classes of those “bag of bits” could be public
>>> classes, and developers may interact with those using the .val. Unsure yet. As
>>> we explore and learn more the approach could change. I hope the exploration
>>> will be informative.
>> 
>> 
>> The problem of the current API is that it only works if everything is inlined by
>> C2, otherwise performance is awful.
>> If a method is not inlined because its assembly code is too big, performance is
>> awful, if a species is not a constant (some students just forget "final" when
>> declaring the species as static final), performance is awful, if an operator
>> (ADD, DIV, etc) is not a constant, performance is awful.
>> 
>> I'm pretty sure, i've already said that but i believe there is a better API
>> design that can work even if a method is not inlined, because being sure that
>> everything is inlined is a hard goal to attain once the code starts to grow.
>> 
>> For that a vector should be a generic value class parametrized by the vector
>> species (so the species is always a constant) with the actual species been
>> private, not visible from the language, an Int128Vector becomes an IntVector at
>> compile time and an IntVector<Int128Species> at runtime.
>> 
>> In that world if a method is not inlined and a value class if a ref, you have
>> nullchecks appearing and those will be hard to see apart taking a look to the
>> assembly code.
>> If an IntVector has no ref companion, you eliminate such kind of performance
>> hiccup.
>> 
>>> 
>>> Paul.
>> 
> > Rémi