8219014: (bf) Add absolute bulk put methods which accept a source Buffer

[Paul Sandoz]

> On Feb 6, 2020, at 12:30 PM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:
> 
> 
>> On Feb 6, 2020, at 12:09 PM, Paul Sandoz <paul.sandoz at oracle.com <mailto:paul.sandoz at oracle.com>> wrote:
>> 
>> To me the spec is quite straightforward, it should behave as is the relative bulk method adjusting and reverting the positional state.
> 
> That’s the behavior, except that in its present form the proposed method allows the source and target buffers to be the same.
> 

Yeah, i was over simplifying.

Hmm… implementation-wise perhaps there is another approach. Make the implementation of the relative put defer to the absolute put.  Thereby moving the implementations across with some minor adjustments rather than duplicating the code?

The relative put would still throw if this == src.  (Its possible to tickle overlapping with heap buffers backed by an explicit array and the relative put methods accepting that same array).

I also now notice the heap/direct implementations can defer to the loopy version via a super call as a final option.  But I still don’t know under what conditions that can occur.

Paul.

>>>> Since buffers are not thread safe the absolute bulk implementation could save the positional state use the relative method and restore the positional state?
>>> 
>>> Without any sort of locking I wonder if that would not be a bit dangerous.
>> 
>> Why? Buffers are anyway stateful and not thread safe.  Composing the implementation from public only methods should ensure the integrity of the buffers is maintained if operated on concurrently (since one can anyway code that up externally).
> 
> That’s true. The implementation proposed here follows more from that used in ByteBuffer.put(int,byte[],int,int).
> 
> Brian

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20200207/3ba66437/attachment.htm>