Adding optional UUID to layouts

Ty Young youngty1997 at gmail.com
Tue Mar 24 12:14:05 UTC 2020


On 3/24/20 6:44 AM, Maurizio Cimadamore wrote:
> We're discussing to open up layout metadata API (which is currently 
> restricted - you can only add layout names now). When that becomes a 
> possibility I believe it would be possible for developers, or for 
> clients such as jextract to decorate layouts more richly than what is 
> being done now (which is the bare minimum). Since layout attributes 
> play in the hashcode/equals dance, that means that similar layout 
> (e.g. 32 bits BE) with different attributes will NOT be considered 
> equals (this is already the case e.g. if layouts have different names).


More public API is of course welcome but I'm not 100% sure if it'll 
cover what I need here since I don't know what specifically would be 
opened up and available.


Some context here, if it helps any,  is that the way I'm going about 
this involves two parts, an "AllocationStack" and an 
"AllocationStackView". The "AllocationStackView" has a list of 
MemoryLayouts which maps what and where things are within the 
"AllocationStack". The problem is that there can be collision when using 
name() from a MemoryLayout(as said before) and it's impossible to tell 
the difference between colliding MemoryLayouts.


For example, two *different* libraries may have the following MemoryLayout:


MemoryLayout.ofValueBits(1, ByteOrder.nativeOrder()).withName("bool");
MemoryLayout.ofValueBits(1, ByteOrder.nativeOrder()).withName("bool");


...which are, of course, the same since they are constructed using the 
same parameters.


What I'm looking for here is a uuid() and withUuid() so that the 
following code is possible:


MemoryLayout.ofValueBits(1, 
ByteOrder.nativeOrder()).withName("bool").withUuid(UUID.randomUUID());
MemoryLayout.ofValueBits(1, 
ByteOrder.nativeOrder()).withName("bool").withUuid(UUID.randomUUID());


>
> Maurizio
>
> On 24/03/2020 11:01, Ty Young wrote:
>> Hi,
>>
>>
>> As was discussed before, I'm working on rigging up a dynamic memory 
>> allocation API. I think I know how to go about it but I need an API 
>> addition from Panama to make it happen since all interfaces are going 
>> to be sealed.
>>
>>
>> This addition comes in the form of a UUID which can be applied to any 
>> given layout. A UUID, unlike a hashcode or a name, is not *intended* 
>> to ever collide(hence UUID) with any other MemoryLayout.
>>
>>
>> Currently both of those do: it's possible that variables or structs 
>> (although, arguably uncommon) from different native libraries have 
>> the same name and hashcode will return the same code given the same 
>> byte size and ByteOrder.
>>
>>
>> Could this be added?
>>


More information about the panama-dev mailing list