<div dir="ltr">Thank you very much for your clarification, although I think some of them still need a very long wait...<br><div><br></div><div>Also, I'll ask another, unrelated little question by the way: How to specify calling convention (cdecl / stdcall) in Valhalla? I didn't find anything relevant, am I missing something?</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 29, 2022 at 11:10 PM 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">
<div>
<p>Hi,<br>
There are few things to be clarified here. Not all segments are
created equals. If you create a segment and attach it to a "real"
session, then escape analysis will fail (as the segment needs to
be added to the session's list).</p>
<p>But the segments returned by the linker (which used to be
MemoryAddress instances) are simpler segment instances, which are
backed by the "global" session. These instances are routinely
scalarized (I believe folks working on LWJGL did some experiments
on this, and reported few issues, which have now been fixed).</p>
<p>Of course, if you take a zero-length memory segment, associated
with the global session, and want to give it a size and a session
(using MemorySegment::ofAddress), that's more expensive (but that
is the same as before).</p>
<p>Lastly, I don't think there's anything preventing us from turning
MemorySegment into value classes, on paper. The tricky thing of
doing that move is to make sure that C2 can see "what kind of
segment are you dealing with", so that the underlying Unsafe
access (for memory operation) can be sharp. In other words, C2
needs to know if the segment has an associated "heap base" (and,
if yes, what's the type of the base object) or not. Otherwise you
end up with the so called "mixed access", where C2 wasn't able to
prove that access was off-heap and extra barriers are inserted. <br>
</p>
<p>That is why, at the moment, we have different memory segment
implementations, one per "kind". We have an abstract class, and
many leaves. Valhalla supports abstract classes too, but abstract
classes need to have no field (which is something we can easily
fix when needed).</p>
<p>But I think the biggest gains would come from having a truly
monomorphic memory segment implementation, although that requires
some C2 optimizations (such as speculating on the types of some
fields) which we do not have yet (but which will likely get more
attention once Valhalla lands, as monomorphi-zation will become a
trick that many people will want to play).</p>
<p>So, in short - the proposed patch doesn't really alter
performance characteristics (zero-length segments backed by global
session are cheap to create and scalarize, like MemoryAddress).
And I think there's no issue in making MemorySegment a value
class, although, to fully reap benefits of Valhalla we might need
more help from C2.</p>
<p>Maurizio<br>
</p>
<p><br>
</p>
<div>On 29/09/2022 15:13, Glavo wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">Sorry for the late reply to the email. I am more
concerned about the following things:
<div><br>
</div>
<div>1. I've asked about Panama's interaction with Valhalla in
previous emails. At the time you said that MemoryAddress
might become a value class in the future.</div>
<div> The value class as a field type may be able to be
stored inline in the future. However, this is not possible
with MemorySegment.</div>
<div>2. MemorySegment as a function parameter may be more
difficult to stack allocated when the function cannot be
inlined.</div>
<div><br>
</div>
<div>I'd like to be able to make native calls through Valhalla
with zero allocation, but this change seems to be further
away from my expectations, so I'm skeptical.<br>
</div>
<div>If I am wrong, I hope you can point it out for
me, thanks!<br>
</div>
<div> </div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Sep 1, 2022 at 5:04
AM Maurizio Cimadamore <<a href="mailto:maurizio.cimadamore@oracle.com" target="_blank">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">What Paul says is
correct, the existing benchmark showed no regression <br>
before/after the change.<br>
<br>
If you know of benchmarks that show a different picture now
would be the <br>
ideal time to share them :-)<br>
<br>
I also note that, in your original message you wrote about a
detrimental <br>
effect on "memory management". What do you mean by that?
Perhaps you <br>
mean more objects being created on the heap?<br>
<br>
In principle, you can view a MemoryAddress in the old API as
a <br>
MemorySegment backed by the global memory session, whose
base address is <br>
a certain native address, and its size is zero. So, if
clients want to <br>
use a segment just to communicate an address in the new API,
and they <br>
create such address-like segments with
`MemorySegment.ofLong(long)`, all <br>
should be fine and escape analysis should work roughly the
same as <br>
before. But again, if you have evidence of the contrary,
please let us know.<br>
<br>
Thanks<br>
Maurizio<br>
<br>
On 25/08/2022 21:59, Paul Sandoz wrote:<br>
><br>
>> On Aug 25, 2022, at 12:51 AM, Glavo <<a href="mailto:zjx001202@gmail.com" target="_blank">zjx001202@gmail.com</a>>
wrote:<br>
>><br>
>> It looks good in terms of simplifying API design,
but this seems to have some detrimental effects on
performance optimization as well as memory management.<br>
>><br>
> Can you please data you have on any performance
regressions you are observing?<br>
><br>
><br>
>> Do we have some benchmarks to show changes in
performance and memory overhead (number of temporary objects
created)?<br>
>><br>
> I believe the existing micro benchmarks show no
regressions:<br>
><br>
> <a href="https://urldefense.com/v3/__https://github.com/openjdk/jdk/tree/master/test/micro/org/openjdk/bench/java/lang/foreign__;!!ACWV5N9M2RV99hQ!P9lRjFpp2u31-nTmHGkNuffRc8WTHIY7ky-3q570E60HzEm3JKxfI6EqGgQPSLDBEbqIm4qlgjF_sJ6vS5JXRh6N1Q$" rel="noreferrer" target="_blank">https://github.com/openjdk/jdk/tree/master/test/micro/org/openjdk/bench/java/lang/foreign</a><br>
><br>
> Paul.<br>
><br>
><br>
>> On Tue, Jul 19, 2022 at 10:05 PM Maurizio
Cimadamore <<a href="mailto:maurizio.cimadamore@oracle.com" target="_blank">maurizio.cimadamore@oracle.com</a>>
wrote:<br>
>> Hi,<br>
>> The Java 19 Foreign Function and Memory API (FFM
API) uses zero-length<br>
>> memory segments to encode pointers that are
temporally safe (this<br>
>> replaces the NativeSymbol abstraction that was
available in Java 18).<br>
>> It turns out that there's more to this approach
than meets the eye, as<br>
>> memory segments can (with few tweaks) be used as a
replacement for<br>
>> memory address everywhere in the FFM API, which
leads to a simpler and<br>
>> more symmetric API.<br>
>><br>
>> We have captured our findings in the following
document:<br>
>><br>
>> <a href="http://cr.openjdk.java.net/~mcimadamore/panama/segment_address.html" rel="noreferrer" target="_blank">http://cr.openjdk.java.net/~mcimadamore/panama/segment_address.html</a><br>
>><br>
>> Cheers<br>
>> Maurizio<br>
>><br>
>><br>
</blockquote>
</div>
</div>
</blockquote>
</div>
</blockquote></div>