Pinning of on-heap MemorySegment

[Jorn Vernee]

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/cc402502/attachment-0001.htm>