compose MemorySegments

[Chris Hegarty]

Only tangentially related...

While decoding HTTP/2 frames, the Java HTTP Client has a threshold
whereby it decides to either copy-accumulate or parse-in-place. Mainly
to avoid slow or pathological inbound network data, where the cost of
aggregation can vastly outweigh the cost of a simple copy.

Response body data is represented as an aggregate of ByteBuffers (there
is no composite ByteBuffer). As with any scatter/gather or aggregation,
the options mostly boil down to somthing like an array or List (the HTTP
Client uses the latter). While this is less friendly to consumers of
said data, at least they know what they get. We've not had any real
issues arise from this in practice.

-Chris H

> On 11 Jun 2021, at 14:40, Chris Vest <mr.chrisvest at gmail.com> wrote:
> 
> In Netty we have a handler called ByteToMessageDecoder which I think
> implements Douglas's use case.
> Bytes come in, in chunks determined by IO, get collected, and then leave in
> chunks of one whole message per chunk, whatever that means for the
> implemented protocol in question.
> Our ByteToMessageDecoder can use the CompositeByteBuf as Douglas described,
> when collecting the incoming bytes.
> However, the extra indirections on every memory access, introduced by the
> CompositeByteBuf, turns out to be expensive in practice, so we actually use
> copying by default.
> The ByteToMessageDecoder can be configured to operate in either mode.
> 
> Cheers,
> Chris
> 
> On Fri, 11 Jun 2021 at 13:09, Maurizio Cimadamore <
> maurizio.cimadamore at oracle.com> wrote:
> 
>> One thing I saw which is very similar to what you want is this:
>> 
>> https://netty.io/4.0/api/io/netty/buffer/CompositeByteBuf.html
>> 
>> Perhaps Chris Vest or some other folks in Netty can comment more on that
>> API. Netty is also doing some exploratory work to validate use of memory
>> segments within Netty itself [1].
>> 
>> Maurizio
>> 
>> [1] - https://github.com/netty/netty-incubator-buffer-api
>> 
>> On 11/06/2021 00:41, Douglas Surber wrote:
>>> As I understand them, no a mapped MemorySegment wouldn't work. The data
>> is not in a file. It is in byte[]s. My code has to look at the bits as it
>> gets them from the network to deal with metadata. Based on that it copies
>> the data bits from the network buffer into byte[]s with no additional
>> processing.
>>> 
>>> Douglas
>>> 
>>> On Jun 10, 2021, at 4:24 PM, panama-dev-request at openjdk.java.net<mailto:
>> panama-dev-request at openjdk.java.net> wrote:
>>> 
>>> Would a mapped MemorySegment work for you?
>>> 
>>