> On 10 Feb 2016, at 14:16, Chris Vest <mr.chrisv...@gmail.com> wrote: > > It’d be a shame to loose the no-zeroing optimisation, so if that requires a > constructor, then lets find a constructor. > > To recap, I have possibly multiple buffers and I only want to use parts of > each. So with the composed buffer I’d have to first extract view buffers and > then compose those, so I end up with 3 levels of buffers. Not ideal. A value > type as a tuple of a buffer reference, an offset and a length would be > better. We could make an array of those and pass that in. It could also find > uses elsewhere in JDK where the buffer+offset+length pattern occurs. The > array, a long with an encoding, could be passed up front to a String > constructor (or a static method – I don’t care) and my use case would be > equally satisfied. >
Perhaps not necessarily 3, since ByteBuffer.slice does not wrap (IIRC wider views do, but that is an implementation detail to share code for heap and direct AFAICT [*]). An absolute slice(int pos, int limit) method might be useful. IMO the more we can simplify the consumer the better with regards to dealing with a sequence of regions. > If I’ve understood correctly, there’s a plan (or at least a great desire) to > turn Optional into a value type once they become available. Yes, there is certainly a strong desire. The risk of course is we have no way of enforcing it be used under constraints of being value-based (or as if a value type). > These “buffer slice” objects could follow a similar path, and thus be made > available independently of value types. Even if they can’t, the overhead they > add would be small, I imagine. > Project Panama will most likely require some form of memory region type, on or off-heap, and that would certainly be a value type (or value-based in the interim). So something may emerge, just not in the short term. Thus i think it would be premature to introduce something specific in Java 9. > I’m slightly more worried about their array and what it implies, though. This > API requires of me that I’m able to present all of the relevant buffers up > front. In my case, these buffers are shared between multiple threads, so they > are guarded by locks. I must take all the locks for all the buffers and hold > them for the duration of the copy. _Maybe_ I have to do that anyway, but if > there’s a way for me to only lock one buffer at a time, I’d like to be able > to exploit this. The builder approach holds this door open for me. > That’s true. Interesting requirements, thanks for sharing. Paul. [*] which i suspect could be made more efficient if we unified heap/direct access
