8219014: (bf) Add absolute bulk put methods which accept a source Buffer
Paul Sandoz
paul.sandoz at oracle.com
Thu Feb 6 20:09:33 UTC 2020
> On Feb 6, 2020, at 11:53 AM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:
>
> Hi Paul,
>
>> On Feb 6, 2020, at 11:32 AM, Paul Sandoz <paul.sandoz at oracle.com <mailto: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.
Ok.
To me the spec is quite straightforward, it should behave as is the relative bulk method adjusting and reverting the positional state.
>
>> 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).
Paul.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20200206/1fbd9f72/attachment-0001.htm>
More information about the nio-dev
mailing list