<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">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://github.com/openjdk/jdk/tree/master/test/micro/org/openjdk/bench/java/lang/foreign" 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>