On implementing interfaces like "SeekableByteChannel" for MemorySegment's

[Maurizio Cimadamore]

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/3c935d95/attachment-0001.htm>