<div dir="ltr">Thanks for your answer! <div><br></div><div>I have several examples for using heap segments to replace native segments usage:</div><div><br></div><div>1. For each web client thread (Could be platform thread or virtual thread), calling connect() function would use a `sockaddr` struct, and that's all, it's a quite small memory allocation, and non-blocking connect will be returned immediately, in scenarios like this, I think it's better to not use an Arena, but to use heap allocation, which is much easier and should be taken well care of by the GC.</div><div><br></div><div>2. When we are sending some messages over the network, the message size are not known before, so will filling the buffer, some array-expansion mechanism like ArrayList would be needed, instead of calling realloc(), I think heap allocation should be better, since GC is really good at doing that.</div><div><br></div><div>3. Sometimes we have to aggregate many chunks of small memorysegment into the final one for native function call, these small memory chunks doesn't need to be native memory, and they are really short-lifecycled.</div><div><br></div><div>All the senarios requires no memset() at all, because developers do know about which part of memory should be overwritten if we are using MemorySegment for native functions call, and I have tested the performance drop at zeroing out the memory when allocated, it's nearly half of the total allocation time.</div><div><br></div><div>I have written a HeapArena class for Heap memory allocation and it works well (by using new long[], which requires some waste of memory, I think that's totally fine), it's just the zeroing issue that makes heap segment allocation not that fast as predicted, and I currently can't do anything about it.</div><div><br></div><div>Reusing heap segment would solve this problem, but as I listed, the use case are usually arbitrary small allocations, where I definitely don't want something like ThreadLocal cache to get involved.</div><div><br></div><div>So in my opinion, it's better if JDK could provide a mechanism, to allocate a heap MemorySegment, with given byteSize and byteAlignment, without zeroing, for these use cases.</div><div><br></div><div>Best regards!</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Per-Ake Minborg <<a href="mailto:per-ake.minborg@oracle.com">per-ake.minborg@oracle.com</a>> 于2024年3月28日周四 01:50写道：<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 class="msg1189817447988651161">




<div dir="ltr">
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
Hi and thank you for the encouragement!</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
I am a bit uncertain as to why you would like to generally work with heap segments if you do not simultaneously have access to the corresponding backing arrays?<br>
<br>
1 and 2) What you could do is to implement your own HeapArena that allocates a larger segment up front and perhaps also support recycling of</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
memory. The latter feature will avoid zeroing out recycled memory portions but will come with additional security caveats as old content now can leak. <br>
<br>
</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
3) At the very end of Jorn's article, you can read more on VarHandles and invoke exact behavior. In short, this will not affect your performance in most cases as the C2 compiler will be able to see through the code. You can also experiment with setting the
 system property parameter "java.lang.invoke.VarHandle.VAR_HANDLE_SEGMENT_FORCE_EXACT" to "true" if you want to see what actually happens under your specific workloads.</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
Best, Per Minborg</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
<br>
</div>
<div id="m_-2066678139183060524appendonsend"></div>
<hr style="display:inline-block;width:98%">
<div id="m_-2066678139183060524divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> panama-dev <<a href="mailto:panama-dev-retn@openjdk.org" target="_blank">panama-dev-retn@openjdk.org</a>> on behalf of 刘希晨 <<a href="mailto:benrush0705@gmail.com" target="_blank">benrush0705@gmail.com</a>><br>
<b>Sent:</b> Wednesday, March 27, 2024 5:47 PM<br>
<b>To:</b> <a href="mailto:panama-dev@openjdk.org" target="_blank">panama-dev@openjdk.org</a> <<a href="mailto:panama-dev@openjdk.org" target="_blank">panama-dev@openjdk.org</a>><br>
<b>Subject:</b> Can we have some heap segment allocation API in the future?</font>
<div> </div>
</div>
<div>
<div dir="ltr">Hi there, I am really happy that Panama-FFI finally released, congratulation! 
<div><br>
</div>
<div>I have been using Panama's features since JDK19, and when I am migrating to JDK22, I found that Heap segment could be passed to native functions if the call is really short, which is really helpful in lots of ways.</div>
<div><br>
</div>
<div>However, allocating heap segments are not so convenient as allocating  native segments, it seems that we could only use MemorySegment.ofArray() to transform an array into a memorysegment.</div>
<div><br>
</div>
<div>Hence I got several question:</div>
<div><br>
</div>
<div>1. Could there be a HeapArena, which targets at allocating heap segments with given byteSize and byteAlignment, just like native segments? That would be pretty helpful in a lot of scenarios.</div>
<div><br>
</div>
<div>2. Could there be an API, for developers, to allocate a heap segment, with no zero-bytes filled, so that heap allocation would be much faster?</div>
<div><br>
</div>
<div>3. I noticed that, when calling MemorySegment.get() or MemorySegment.set() methods, it will use the underlying Varhandle to do the job, I read about Varhandle in <a href="https://jornvernee.github.io/methodhandles/2024/01/19/methodhandle-primer.html" target="_blank">https://jornvernee.github.io/methodhandles/2024/01/19/methodhandle-primer.html</a>,
 and when I run the following code:</div>
<div><br>
</div>
<div>
<div style="background-color:rgb(30,31,34);color:rgb(188,190,196)">
<pre style="font-family:"Cascadia Mono",monospace;font-size:10.5pt">System.<span style="color:rgb(199,125,187);font-style:italic">out</span>.println(ValueLayout.<span style="color:rgb(199,125,187);font-style:italic">JAVA_INT</span>.varHandle().hasInvokeExactBehavior());</pre>
</div>
</div>
<div><br>
</div>
<div>the result is false, so there is no InvokeExactBehaviour, which is not recommended. I thought this could be a mistake, or it's intended to handle the auto-boxing conversion, please take a look at this.</div>
<div><br>
</div>
<div>Best regards!</div>
</div>
</div>
</div>

</div></blockquote></div>