<div dir="ltr">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.<div><br></div><div>Just my $0.02. Thanks a lot.</div><div>Quan Anh</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 29 Aug 2023 at 00:59, Maurizio Cimadamore <<a href="mailto:maurizio.cimadamore@oracle.com">maurizio.cimadamore@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
On 28/08/2023 17:56, Radosław Smogura wrote:<br>
> I think other approach would be for ImageIO to use MemorySegment instead of operating on int arrays.<br>
><br>
> For programming like CUDA this can bring additional benefits like using memory mapping between host and device.<br>
<br>
I 100% agree with this.<br>
<br>
Again, I don't dispute the performance benefit of pinning - but, with a <br>
different API, there would be no reason to do pinning (nor copy) in the <br>
first place. It might be that pinning is the "pragmatic" solution to <br>
interact with such array-biased APIs, but I also hope we can fix some of <br>
the tension in the existing APIs (especially if such APIs happen to be <br>
in the JDK).<br>
<br>
Maurizio<br>
<br>
</blockquote></div>