On implementing interfaces like "SeekableByteChannel" for MemorySegment's

[Gavin Ray]

Awesome, thank you so much for your help and the clarification!

On Fri, Sep 9, 2022 at 11:09 AM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

>
> On 09/09/2022 16:01, Gavin Ray wrote:
>
> Got it -- and do you still have to pay cleaner costs or any other overhead?
>
> 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.
>
> 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 :-) ).
>
> Maurizio
>
>
> I would assume not because "MemorySegment" lifecycle is managed by
> "MemorySession" but want to make sure I understand the implementation
> correctly
>
> On Fri, Sep 9, 2022 at 10:17 AM Maurizio Cimadamore <
> maurizio.cimadamore at oracle.com> wrote:
>
>>
>> On 09/09/2022 15:02, Gavin Ray wrote:
>>
>> Ah, I didn't realize that there was negligible overhead for wrapping as a
>> buffer
>>
>> That makes sense, so you're just allocating a single Object wrapping a
>> zero-copy slice of the underlying buffer essentially?
>>
>> 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.
>>
>> Maurizio
>>
>>
>>
>> On Fri, Sep 9, 2022 at 9:58 AM Maurizio Cimadamore <
>> maurizio.cimadamore at oracle.com> wrote:
>>
>>> Hi Gavin,
>>> for now we have no plans to provide I/O APIs to take memory segments
>>> instead of buffers.
>>>
>>> When working with I/O it is preferrable to map the segment into a buffer
>>> (which is a very cheap operation, no copy is required, only a view is
>>> created).
>>>
>>> Maurizio
>>>
>>> On 09/09/2022 14:46, Gavin Ray wrote:
>>> > We can see in the JavaDoc for FileChannel that "transferTo/From" is
>>> > the way to use potentially optimal I/O transfers
>>> > This requires a Readable/Writeable/SeekableByteChannel, which have
>>> > "ByteBuffer" as the argument types
>>> >
>>> > Are there any plans to eventually modify I/O API's to take raw
>>> > MemorySegment's for better performance?
>>> > Or should folks just do MemorySegment.ofBuffer() etc?
>>> >
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20220909/537df2d7/attachment-0001.htm>