<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
Even though pinning might seem like a very useful feature to have
for all those cases in client/desktop/imaging<br>
where we have large Java byte arrays, and don't have the option for
those to live only off-heap because they<br>
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<br>
native access to those. I'd look high and low or other performance
solutions first .. <br>
<br>
We have 174 uses of GetPrimitiveArrayCritical in the java.desktop
module, and have to be very careful about those,<br>
and I'm not sure I'd want to see 174 such calls in Java-level code.
<br>
<br>
It's a difficult problem but a Java pinning API feels like jumping
to a familiar but non-ideal solution <br>
<br>
-phil.<br>
<br>
<div class="moz-cite-prefix">On 8/28/23 10:42 AM, Jorn Vernee wrote:<br>
</div>
<blockquote type="cite" cite="mid:ac170b06-b97e-2aa2-106c-5bea829b236d@oracle.com">
<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>
</blockquote>
<br>
</body>
</html>