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

[Brian Burkhalter]

Hi Paul,

> On Feb 6, 2020, at 11:32 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> 
> I think an absolute bulk put method is useful (see below for caveat).  
> 
> There is some inconsistency with the existing relative bulk specifications and implementations when this and the source buffers overlap.

Yes, in the other case we get an IAE.

> The loopy implementation overwrites but heap buffers defer to System.arraycopy and direct buffers defer to UNSAFE.copyMemory, I believe both make temporary copies on overlapping regions.  I am uncertain about when the loopy version is called.

Right. I have not looked into the specifics of the heap and direct implementations yet, preferring to wait until we decide whether to move forward with this. I don’t know that the loopy version is ever called, actually. It looks like all possible combinations of endianness, [un]swapped, {RW,RO} are generated from the templates.

> —
> 
> The new MemorySegment API supports creating segment views from buffers, from which a bulk copy can be performed using memory address within those segments (overlapping ranges create temporary copies).
> 
> This gives me pause on such enhancements to Buffers.  There is some tedious amount of work required to ensure all buffer implementations do the right thing. But, work required by a developer to transition from the buffer domain to segment and address domain is not so trivial either.
> 
> If we can find a way to simplify the work in buffer I could be persuaded to add this method.

I think the required work would not be that much given the similarity to other existing code, at least once the specification were agreed.

> 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.

Thanks for reviewing.

Brian

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