Adding optional UUID to layouts

[Maurizio Cimadamore]

On 24/03/2020 15:07, Ty Young wrote:
>
> On 3/24/20 9:18 AM, Maurizio Cimadamore wrote:
>>
>> On 24/03/2020 12:14, Ty Young wrote:
>>> MemoryLayout.ofValueBits(1, 
>>> ByteOrder.nativeOrder()).withName("bool").withUuid(UUID.randomUUID()); 
>>
>> What I'm saying is that withName is just a withAttribute(NAME, 
>> "bool"), where an attribute can be any Java object that implements 
>> the Constable interface. So it might be possible to do something like
>>
>> layout.withAttribute("library", "OpenGL")
>>
>> and that will make all layouts generated in a given extraction run 
>> 'unique' (since equals() and hashCode() take attributes into account).
>>
>> See:
>>
>> https://git.openjdk.java.net/panama-foreign/pull/64
>>
>> Which Jorn has timely submitted :-)
>
>
> No kidding. It's almost creepy how on top of things like this you all 
> are. I wish I knew these things were being worked on beforehand so I 
> don't end up bothering you all so much.
Heh - we need to do a better job at communicating directions, yes. In 
general we're currently converting a lot of examples using older 
jextract, figuring out what's missing, rinse and repeat. So we're trying 
to see what are the common helper routines a user is likely to need. You 
might expect some more refinements in SystemABI and surrounding APIs 
based on that.
>
>
> Many thanks.
>
>
>>
>> In general - we're NOT going to add a UUID to add layouts just 
>> because in some cases it feels it's handy to have one. But that's why 
>> the layout attribute machinery comes in place - to add extra 
>> side-info to the layout w/o necessarily making the API more complex 
>> with things that most users won't even care about.
>>
>> So, your question can be rephrased as: can jextract please attach a 
>> standard layout attribute to all the layout it emits during a single 
>> run, so that layouts from library A cannot be confused with layouts 
>> coming from library B?
>>
>> Right now we haven't discussed anything in that direction - the new 
>> API (see above PR) makes it possible; another possibility is that 
>> your API could be in charge of the decorating process (e.g. if your 
>> API only works with layouts which have an 'uuid' then have a function 
>> which takes a layout and returns a new layout with the desired uuid 
>> embedded as a layout attribute).
>
>
> Right, good idea.
>
>
> A question here, if you don't mind, is does the JVM have memory 
> optimizations for things like ValueLayout? Or is ValueLayout manually 
> optimized by passing object instances through the constructor?

Not sure I follow - you mean if the JVM optimizes ValueLayout instances 
in any way, to make them take less space and all that? If so, no, the VM 
does nothing - although, the fact that layouts are immutable and value 
friendly will make them more amenable to become inline classes one day, 
at which point they will get the same optimizations as the other inline 
classes.

Maurizio

>
>
>>
>> Maurizio
>>