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

[Michael Zucchi]

Hi guys,

On 25/3/23 07:52, Maurizio Cimadamore wrote:
>
> Hi Glavo,
> that's a very interesting comparison, thank you!
>
> We will look into the C string -> Java string issue. There are 
> probably "tricks" [1] that native strlen does which we could replicate 
> in our Java code (or we could just do a trivial call to strlen :-) ).
>

It's way more than tricks, at least glibc has hand-rolled architecture 
and feature (sseX/avxX/neon/etc) specific assembly versions in addition 
to the inline stuff available at compile time. I was definitely 
surprised when i noticed getUItf8 was doing it's own strlen.

Doing the trivial call to strlen leverages so much development effort 
and technology - and which will continue to be state-of-the-art - so it 
seems silly not to just call it.

> Aso for struct layouts, I think it is a reasonable request - e.g. 
> allow creation of struct layouts which are "padded" correctly. But I 
> think we'd still want to retain the "raw" variant, which might be 
> useful for tools such as jextract.
>

I was always puzzled why it doesn't enforce alignment based on the 
ValueLayout's alignment and automatically calculate the padding 
required.  Even if you override the system ABI via packed or align 
__attribute__'s members still have a natural alignment that can be 
expressed precisely and completely via an appropriate ValueLayout. A C 
compiler _always_ enforces the rules by necessity.

At the moment you can trivially create an illegal structure layout, e.g. 
(JAVA_BYTE, JAVA_LONG).  But the alignment is still enforced anyway when 
you try to create a varhandle from it so being able to create such a 
struct layout is effectively worthless.  And aren't these invalid 
structures the only type of layout that the 'raw' variant allows that a 
'non-raw' one wouldn't?

So I fail to see a scenario where enforcing the alignment of the member 
based on the ValueLayout.bitAlignment() wouldn't always lead to the 
correct behaviour.  And doing so would necessarily automatically 
calculate any padding.  Also ensuring the memorylayout's are valid 
initially could potentially remove some (repeated) checks in other places.

But adding padding is still a very useful feature and still required.  
Mainly to skip members - some members might not be relevant to java, or 
private fields (either by comment or void *), or if you're only 
interested in a few of many members.  Although it would be nice if one 
had a 'withOffset()' call - the gcc plugin i use to determine structure 
offsets provide the bit offset directly so one needs to calculate the 
padding required by *Layout from the offsets - which it then just has to 
recalculate into an offset again anyway.  Presumably jextract has to do 
the same.

I would be nice if the layout api didn't require naming every field to 
be useful, it's just so much metadata which is often never needed and it 
can add up.  But if you don't name your layout's you can't access them 
from java.  One day I intend to compare 'raw' access (e..g 
segment.get(xx, offset) verses using any of the GroupLayout stuff in 
terms of class sizes and performance for some large api (vulkan is the 
obvious one), but I've been afk or playing with other stuff lately and 
somewhat lost track of where i was on that project.

  Z