Pinning of on-heap MemorySegment

[Maurizio Cimadamore]

CC'ing Gary, who has been looking at this problem from the GPU side of 
the fence :-)

Maurizio

On 28/08/2023 19:39, Philip Race wrote:
> 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/20230830/e292b2bc/attachment.htm>