On implementing interfaces like "SeekableByteChannel" for MemorySegment's

[Gavin Ray]

Got it -- and do you still have to pay cleaner costs or any other overhead?

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/4d244fe8/attachment.htm>