Question: ByteBuffer vs MemorySegment for binary (de)serializiation and in-memory buffer pool

[Johannes Lichtenberger]

Yesterday I thought about it and maybe a higher level API on top of the
Foreign Memory API with MemorySegment, MemoryLayout and VarHandles... would
also be nice. Often times you'd simply want to use it as a replacement for
ByteBuffer it seems and a fluent API like this is pretty nice IMHO (from
the ByteBuffer Javadoc):

bb.putInt(0xCAFEBABE).putShort(3).putShort(45)

Kind regards
Johannes

Am Mi., 24. Aug. 2022 um 02:34 Uhr schrieb Michael Zucchi <notzed at gmail.com
>:

> On 23/8/22 03:57, Gavin Ray wrote:
> > Thanks Paul,
> >
> > The API is a fair bit wordier, but that's the price you pay in
> > exchange for greater expressiveness and flexibility I suppose.
> > I'll likely go forward with the MemorySegment implementation then -- I
> > appreciate the reply!
> >
> TBH it probably wont turn out to be wordier once you get it worked out.
> ByteBuffer was better than nothing but MemorySegment is cleaner for
> memory access as it doesn't carry the nio baggage.  And some of the
> boilerplate better encapsulates various operations you would need to
> perform separately anyway.
>
> Also one doesn't need to do any deserialisation for many types of
> accesses since you can just access the memory directly via varhandles.
> If the data is not packed but naturally aligned and ordered then
> accessing it via var handles into primitive types is simple and more
> efficient than marshalling to another object first.
>
> e.g.
>   in C, 'slot[i].offset' could become
> 'slot$offset$varhandle.get(segment, i)' which you through in an accessor
> on some object like Page which holds the segment.
>
> where the varhandle is something like
>
> static VarHandle slot$offset$varhandle =
> slotLAYOUT.sequenceLayout().varHandle(
>          MemoryLayout.PathElement.sequenceElement(),
>          MemoryLayout.PathElement.groupElement("offset"));
>
>   !Z
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20220824/5ce06067/attachment-0001.htm>