<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>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. </p>
<p>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.<br>
</p>
<p>Jorn<br>
</p>
<div class="moz-cite-prefix">On 28/08/2023 19:25, Quân Anh Mai
wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAPvyiyJkd05HUD2sYpim0FufwQVhKd-=jempEAbLMq-cyA_bkQ@mail.gmail.com">
<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" moz-do-not-send="true" class="moz-txt-link-freetext">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>
</blockquote>
</body>
</html>