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

[Maurizio Cimadamore]

On 26/03/2023 03:24, Michael Zucchi wrote:
>
> 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.
If you have a heap segment, calling native strlen would not work.
>
>> 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.
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.
>
> 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.

Naming is not required - we have added a new 
PathElement.groupElement(long index) to get the nested field layout at 
position "index" inside a struct.

Maurizio

>
>  Z
>