Pinning of on-heap MemorySegment

[Philip Race]

Even though pinning might seem like a very useful feature to have for 
all those cases in client/desktop/imaging
where we have large Java byte arrays, and don't have the option for 
those to live only off-heap because they
are speced to be Java byte[], I'd still not be sure I'd start out by 
asking for a Java-level pinning API to support
native access to those. I'd look high and low or other performance 
solutions first ..

We have 174 uses of GetPrimitiveArrayCritical in the java.desktop 
module, and have to be very careful about those,
and I'm not sure I'd want to see 174 such calls in Java-level code.

It's a difficult problem but a Java pinning API feels like jumping to a 
familiar but non-ideal solution

-phil.

On 8/28/23 10:42 AM, Jorn Vernee wrote:
>
> I agree. Not having pinning pushes people to a more performant model 
> that uses off-heap memory throughout. The downside being that it 
> requires more effort on the part of the client. In other words, 
> pinning is a local maxima. I mostly see pinning support as a way to 
> get feature parity with JNI.
>
> I also think that pinning support in FFM should be designed in such a 
> way that we can degrade the functionality if we wanted to, e.g. by 
> falling back to doing copies. Since it's tied so much to the VM 
> implementation, I  think we don't want to restrict future VM 
> development by making too many promises about what the VM does when a 
> client uses pinning. I definitely think we should not name it 
> 'pinning' for that reason as well.
>
> Jorn
>
> On 28/08/2023 19:25, Quân Anh Mai wrote:
>> Counter point: Not having pinning features discourages developers 
>> from using heap segments with native funtions. People who want to 
>> achieve the optimal performance should not use heap segments with 
>> native functions, and should use native segments from the beginning. 
>> For the others, memory copying is blazingly fast and you will not 
>> need the additional performance by avoiding copying. Note that the 
>> JVM itself does memory zeroing of arrays all the time, and this 
>> operation has similar performance characteristics to memory copying. 
>> This also avoids adding obscure caveats into the APIs, I disagree 
>> with the idea that all bets are off going into native, as there are 
>> different kinds of issues, and the kind to which locking the GC 
>> belongs is among the hardest ones to deal with.
>>
>> Just my $0.02. Thanks a lot.
>> Quan Anh
>>
>> On Tue, 29 Aug 2023 at 00:59, Maurizio Cimadamore 
>> <maurizio.cimadamore at oracle.com> wrote:
>>
>>
>>     On 28/08/2023 17:56, Radosław Smogura wrote:
>>     > I think other approach would be for ImageIO to use
>>     MemorySegment instead of operating on int arrays.
>>     >
>>     > For programming like CUDA this can bring additional benefits
>>     like using memory mapping between host and device.
>>
>>     I 100% agree with this.
>>
>>     Again, I don't dispute the performance benefit of pinning - but,
>>     with a
>>     different API, there would be no reason to do pinning (nor copy)
>>     in the
>>     first place. It might be that pinning is the "pragmatic" solution to
>>     interact with such array-biased APIs, but I also hope we can fix
>>     some of
>>     the tension in the existing APIs (especially if such APIs happen
>>     to be
>>     in the JDK).
>>
>>     Maurizio
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20230828/8db225b2/attachment-0001.htm>