MemoryLayout api

[Maurizio Cimadamore]

On 21/01/2020 15:44, forax at univ-mlv.fr wrote:
>
>
> ------------------------------------------------------------------------
>
>     *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é: *Mardi 21 Janvier 2020 16:28:30
>     *Objet: *Re: MemoryLayout api
>
>
>     On 21/01/2020 15:17, Remi Forax wrote:
>
>         Hi all,
>         i've played a little bit with the current version used by the jdk 15 and the one in the branch foreign-memaccess (for the benchmarks).
>
>         I really like the API, the MemoryLayout part in particular.
>
>         I will do a presentation in two weeks about the foreign API (and everythings else introduced in jdk 14)
>            https://github.com/forax/do-synthetic-methods-dream-of-electric-switch-expressions
>         All my tests are available as a python notebook (see the README).
>
>     Thanks for the comments Remi
>
>         There is something i don't understand.
>         The memory layout API let you create layouts that are invalid, i.e. that you can not create any VarHandle on it,
>         by example a group (struct or union) that contains a sequence without a size, or a layout that starts with two sequences with no size.
>
>         I get why you can have one sequence free, but you can not have more than one, otherwise you can not compute the size of the inner layout.
>
>         So why the layout API let users create such badly shaped layout ?
>         May i have overlooked something ?
>
>     Well, in principle, a sequence without a size is just a layout
>     with a size 'hole' in it. If you find a way to 'plug' the hole
>     (let's say that all the unsized sequence layouts are preceeded by
>     a ValueLayout which specifies the sequence size), then there's a
>     way for you to obtain a new layout, derived from the first, which
>     is actually usable for allocation/VarHandle computation.
>
>
> I've written something like this, that plug the holes
> ses 
> https://github.com/forax/do-synthetic-methods-dream-of-electric-switch-expressions/blob/master/chapter07-foreign_memory_api.jsh#L442
>
>     So, in a way, this is to make the layout API partially usable with
>     variable-sized structures. Think about classfile attributes e.g.
>
>     RuntimeInvisibleParameterAnnotations_attribute {
>          u2 attribute_name_index;
>          u4 attribute_length;
>          u1 num_parameters;
>          {   u2         num_annotations;
>              annotation annotations[num_annotations];
>          } parameter_annotations[num_parameters];
>     }
>
>     These can have multiple sequences whose size is bound dynamically
>     - and not statically, right?
>
>
> yes, there is a lot of binary protocols where  you have the size that 
> is provided just before the values.
> but to be efficient, the varHandles has to be constant, so the layout 
> has to be constant too.

Yes - I agree - the story is not fully baked here. What I'd like to do 
is, eventually, to provide "partially" instantiated var handles, where 
all sizes left unspecified in the layout must be provided as an extra 
acquired dimension.

I think this will bring back things to static-ness - what do you think?

Maurizio

>
>     Maurizio
>
>
> Rémi
>
>
>         regards,
>         Rémi
>
>
>