<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 09/09/2022 16:01, Gavin Ray wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAFtvWZPLF_Z3LwRvGea6Od2-9Dv8OJsjuc5M+LNyygPr7gTZ4Q@mail.gmail.com">
<div dir="ltr">Got it -- and do you still have to pay cleaner
costs or any other overhead?</div>
</blockquote>
<p>No, the returned buffer is attached to the same memory session as
the segment. And it can only be accessed if the session is alive.
No cleaner cost involved.</p>
<p>The returned buffer also inherits the same thread-confinement
restriction of the original segment. So if the segment is
confined, the resulting buffer is also confined (which is kind of
a new thing for the ByteBuffer API :-) ).<br>
</p>
<p>Maurizio<br>
</p>
<blockquote type="cite" cite="mid:CAFtvWZPLF_Z3LwRvGea6Od2-9Dv8OJsjuc5M+LNyygPr7gTZ4Q@mail.gmail.com">
<div dir="ltr">
<div><br>
<div>I would assume not because "MemorySegment" lifecycle is
managed by "MemorySession" but want to make sure I
understand the implementation correctly</div>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Fri, Sep 9, 2022 at 10:17
AM 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><br>
</p>
<div>On 09/09/2022 15:02, Gavin Ray wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Ah, I didn't realize that there was
negligible overhead for wrapping as a buffer
<div><br>
<div>That makes sense, so you're just allocating a
single Object wrapping a zero-copy slice of the
underlying buffer essentially?</div>
</div>
</div>
</blockquote>
<p>Yes, a direct buffer instance has some starting
(off-heap) address and a size. What
MemorySegment::asByteBuffer does is simply to create a new
(direct) ByteBuffer instance, whose base address is set to
the base address of the segment, and the size is set to
the segment size. This way, the byte buffer can "see" all
the bytes in the memory segment.</p>
<p>Maurizio<br>
</p>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Fri, Sep 9, 2022 at
9:58 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">Hi Gavin,<br>
for now we have no plans to provide I/O APIs to take
memory segments <br>
instead of buffers.<br>
<br>
When working with I/O it is preferrable to map the
segment into a buffer <br>
(which is a very cheap operation, no copy is required,
only a view is <br>
created).<br>
<br>
Maurizio<br>
<br>
On 09/09/2022 14:46, Gavin Ray wrote:<br>
> We can see in the JavaDoc for FileChannel that
"transferTo/From" is <br>
> the way to use potentially optimal I/O transfers<br>
> This requires a
Readable/Writeable/SeekableByteChannel, which have <br>
> "ByteBuffer" as the argument types<br>
><br>
> Are there any plans to eventually modify I/O
API's to take raw <br>
> MemorySegment's for better performance?<br>
> Or should folks just do MemorySegment.ofBuffer()
etc?<br>
><br>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</body>
</html>