<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>CC'ing Gary, who has been looking at this problem from the GPU
side of the fence :-)</p>
<p>Maurizio<br>
</p>
<div class="moz-cite-prefix">On 28/08/2023 19:39, Philip Race wrote:<br>
</div>
<blockquote type="cite" cite="mid:40a0dbba-5c92-9bfa-741d-b7e5362b8ab7@oracle.com">
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>
</blockquote>
</body>
</html>