<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 29/09/2022 17:36, Glavo wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAJL5A3k-GcKTwkTMCD0xJe037aci1VneCnSqyJXXCHZBjjqUVw@mail.gmail.com">
<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>
</blockquote>
<p>I think you mean Panama, not Valhalla?</p>
<p>We have recently added support for "Linker options" to the API
[1], e.g. options that alter the behavior of a linkage request; we
plan to use this for various things, such as:</p>
<p>* pinning of heap segments<br>
* saving errno/LastError<br>
* maybe deal with signals coming from native code (some libraries
use them to communicate errors)<br>
* mark a native call as a "trivial" and omit native state
transitions<br>
* ...</p>
<p>I think adding support for different calling convention dialects
is something that can also be added in this way.</p>
<p>Maurizio<br>
</p>
<p>[1] - <a class="moz-txt-link-freetext" href="https://git.openjdk.org/panama-foreign/pull/734">https://git.openjdk.org/panama-foreign/pull/734</a><br>
</p>
<p><br>
</p>
<blockquote type="cite" cite="mid:CAJL5A3k-GcKTwkTMCD0xJe037aci1VneCnSqyJXXCHZBjjqUVw@mail.gmail.com"><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" 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">
<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" 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">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" moz-do-not-send="true" class="moz-txt-link-freetext">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" moz-do-not-send="true">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" moz-do-not-send="true" class="moz-txt-link-freetext">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" moz-do-not-send="true" class="moz-txt-link-freetext">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>
</blockquote>
</body>
</html>