MemoryLayout api

[forax at univ-mlv.fr]

> De: "Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "panama-dev at openjdk.java.net'" <panama-dev at openjdk.java.net>
> Envoyé: Mardi 21 Janvier 2020 17:00:20
> Objet: Re: MemoryLayout api

> On 21/01/2020 15:44, [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] wrote:

>>> De: "Maurizio Cimadamore" [ mailto:maurizio.cimadamore at oracle.com |
>>> <maurizio.cimadamore at oracle.com> ]
>>> À: "Remi Forax" [ mailto:forax at univ-mlv.fr | <forax at univ-mlv.fr> ] , [
>>> mailto:panama-dev at openjdk.java.net' | "panama-dev at openjdk.java.net'" ] [
>>> mailto: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
>>>> |
>>>> 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
>> |
>> 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?
yes, 
good idea ! 

> Maurizio
Rémi