The storage hint model

[forax at univ-mlv.fr]

> From: "John Rose" <john.r.rose 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, July 21, 2022 4:34:24 AM
> Subject: Re: The storage hint model

> I’m glad to see this idea worked out in detail, and for the record.

> Given we want to give users control at several points over potential flatness,
> we must choose either a separate storage classes channel or a variation in
> variable types themselves.

> And my overall sense is that it’s a “pick your poison” situation. But I think
> complexifying the types goes down a little smoother than adding a new channel
> to most (but not all) variables. Generic variables can benefit from a
> type-based solution, but not from a SC-based solution, as this analysis shows.

> The SC-based solution shrinks the surface of the flat-vs-not choice, but makes
> it correspondingly more irregular.

> One irregularity you don’t mention is signature alignment. In order to link to a
> method or field (or override a method) you need the signatures aligned. (We
> don’t want bridges today please.) This means that the .flat annotations are
> part of the signature (since they compile to Q-types). This means signatures
> depend on something besides types, surely an add to the net complexity.

yes, it's not only storage hints, you also need parameter hints and those have an impact on the binary compatibility apart if we go with the TypeRestriction option (not quite a bridge if you squint). 

> Also, type inference can carry flatness in the design of record, but cannot do
> so in a SC-based design, at least not without more irregular hacks. (Maybe that
> doesn’t matter?)

for me it's a big plus, it means less fight with the type inference for my students. 

> On 20 Jul 2022, at 13:05, [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ]
> wrote:

>> Maybe you want or maybe you don't, here is an interesting implementation of
>> ArrayList

>> public classs ArrayList<E> {
>> private E[] array;
>> private int size;

>> public ArrayList() {
>> array = new E.flat[16]; // ahah, flat by default !
>> }

>> public boolean add(E element) { // E is not flat
>> if (element == null && !array.getClass().isNullable()) {
>> var newArray = new E[array.length]; // need to store null, use a nullable array
>> System.arraycopy(array, 0, newArray, 0, array.length);
>> array = newArray;
>> }
>> if (array.length == size) {
>> array = Arrays.copyOf(array, size * 2);
>> }
>> array[size++] = element:
>> return true;
>> }
>> }

>> It starts with a flat array and if an element null is added, it "unflat" itself.
>> This implementation is interesting because once recompiled with the new
>> generics, a new ArrayList<Integer>() will use a flatten array by default.

>> I've no idea about the performance of such kind of implementations, but using
>> T.flat give better control on what is flattenable or not in the implementation.
> If we choose, we can code this trick in the design of record as well.

You mean in the design of array ? I don't think it's wise given that the shape of the array change, but perhaps GCs can be modified to add a relocate and unflat operation to array. 

> So it’s not an advantage of the .flat proposal; it’s just a trick that is forced
> on the programmer willy nilly.

> Today a variable is a type, and an optional name. If it is a local or a field it
> has a name. If it is inside an array or a (possibly generic) container, there
> is no name. I can refactor my variables all day long through named and unnamed
> temps, fields, arrays, and other containers. If some but not all of those
> locations accept my chosen SC, my refactorings have greater friction.

If the variable is typed by a type variable, yes. But we have decided to have the exact same kind of friction 
- with value class in practice because the VM is able to unmask the value class on stack but not on heap. 
- with wildcards (you have to add those pesky ? extends/super). 

> It seems like adding new types is less disruptive than adding a whole new
> classification for variables.

Rémi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-spec-observers/attachments/20220721/4497f9a4/attachment.htm>