Comparing the performance of Panama with JNI, JNA, and JNR - based on Java 21

[Michael Zucchi]

On 26/3/23 23:16, Maurizio Cimadamore wrote:
> Forgot: another problem is that just offloading to external "strlen" 
> will not respect the memory segment boundaries (e.g. the underlying 
> strlen will keep going even past the spatial boundaries of the memory 
> segment). 

But it'll be a very common case that the strings are from unbounded 
pointers such as query methods that return a pointer or struct members 
of char *.  For such memorysegments it would be an obvious fit.  But I 
suppose if it's actually a problem for anyone they just can roll their 
own implementation.

On 26/3/23 22:52, Maurizio Cimadamore wrote:
> I think allowing easier creation of struct layouts (as I stated in the 
> other email) is a nice to have. The main question is to whether the 
> API should allow for creation of layouts that are "bad" or not. For 
> most use cases, I agree that the preferred answer would be "no" - I 
> wonder if in most advanced cases where a client wants to transform an 
> existing struct layout into a new one, not having the ability to say 
> where padding should go will backfire. 

I'd be curious to know what these "advanced cases" could possibly be?  
And how an object ostensibly for creating varhandles that can't create 
varhandles could have any practical use?  Alignment is enforced 
everywhere else, it seems so arbitrarily inconsistent not to do so here.

As far as I can tell anything you can actually do in c you could also do 
with a layout api that enforced the alignment (and calculated the 
post-struct padding) based on the layout details of the members.  And 
explicit padding layouts could still be used to add arbitrary gaps.

e.g.
struct __attribute__((packed)) a {
   char b;
   int a;
}
sizeof == 5
===
structLayout(JAVA_BYTE.withName("a"), *JAVA_INT_UNALIGNED*.withName("b"));


struct __attribute__((packed)) a {
   char b;
   int a __attribute__((aligned(2)));
}
size == 6
===
structLayout(JAVA_BYTE.withName("a"), 
JAVA_INT.*withBitAlignment(16).*withName("b")); // assuming enforced padding


It's not rocket science - you can only tweak the packing in one way, by 
changing alignment by (2^N) bytes.  C just doesn't have support for 
creating arbitrary bitstreams using struct or union - for anything like 
that you're forced to do it by hand with something like a ByteBuffer.   
If you wanted to translate to or from a packed to non-packed actual 
'struct' you'd just use two separate struct definitions and copy them 
member by member - and you'd have to do the same with MemoryLayout.

I came across an article about the practicalities of the struct packing 
rules - it's mostly based on what maps efficiently to real hardware[1].  
Micrsoft's struct layout is basically the same as gcc[2] apart from 
bitfields, but they're never portable anyway.

Maybe some obscure compilers have other facilities for special purposes 
as they are beyond the c standard.  But this also means the system ABI 
is usually used for struct packing for re-usable libraries, that's sort 
of the whole point of having a system ABI defined - particularly for 
exactly the case of multi-language inter-op that the foreign abi is for.

"maybe it could be useful to someone some time" sounds a lot like over 
engineering to me. Apparently also more specifically called "Boat 
Anchor" "anti-pattern" these days [3].

Anyway  i've said my piece for now and i'll go back to lurking.

  Z

[1] http://www.catb.org/esr/structure-packing/
[2] https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html#index-mms-bitfields
[3] https://en.wikipedia.org/wiki/Boat_anchor_(metaphor)#Software
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20230329/e6351928/attachment-0001.htm>