On implementing interfaces like "SeekableByteChannel" for MemorySegment's

[Maurizio Cimadamore]

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/062add6b/attachment.htm>